Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Thu, 24 Jun 1999 17:33:03 GMT
|
Viewed:
|
1210 times
|
| |
|
|
Ola Liljedahl <olli@enea.se> wrote:
> But hardware interrupts schedule a different context (the interrupt
> process or ISR) from the one already executing. A Unix-style signal
> asynchronously signal interrupts the executing process and jumps to
> a different location in the code that will access and possibly modify
> the state of the same process. This makes it very difficult to maintain
> data consistency.
I think you're missing the point.
Now correct me if I'm wrong, Lou --
I believe the intent of the signal mechanism is to allow a way to specify a
function to run when a system event occurs: e.g. a message arrives across
the IR port. It is somewhat expected that all the typical user would all
you would do in such a function is something simple that does *not* modify
data - e.g. signal a semphore. Of course, the mechanism does not rule out
a more advanced user doing something else, like using the keyword
"volatile" in the appropriate places to make more interesting things
happen.
The same signal mechanism will also allow users to send "POSIX signals" to
other "processes," but personally I do not see the point in this, since all
threads/processes are running in the same address space, so this
functionality is not really needed.
Seeing that it is my turn to pontificate, I should say that there are at
least four ways to implement asynchronous notification of events, which is
the whole topic we're really discussing here:
1) call a function asynchronously when the event occurs
2) signal a semaphore for the event when the event occurs
3) queue the event on an event queue when the event occurs
Here is the argument for (1), which I buy into completely:
- all of these can be implemented by the others
- (1) is the simplest and the smallest
- implement (1), if others want (2) or (3), let them implemented that using (1)
The only argument against (1) might be that it is not the easiest to use,
so naturally the question is what to implement on top of (1) for the
"typical user"? I think the following API would be nice:
#define EV_ ... // event mask bits
wait_event(int mask);
wait_event waits for any event specified by the mask to occur, returns when
that has happened; implementation can be made very efficient on top of (1)
This is mechanism I chose to implement in the "unreleased custom version"
of Librcx I keep mentioning - a version that will get released at some
point, when it's all done, but I'm in no hurry.
-Kekoa
|
|
Message has 2 Replies:
 | | Re: signals / legOS internals
|
| (...) I should add that since many things are vectored in this version of Librcx, overriding functionality is easy for the advanced user to do. For example: extern void (*__event_vector)(void); void my_setup_func() { // ... __event_vector = (...) (25 years ago, 24-Jun-99, to lugnet.robotics.rcx.legos)
| | | Re: signals / legOS internals
|
| (...) When a frame or character has been received by the IR port it signals an interrupt to the processor. The processor (OS) handles this by invoking an ISR (Interrupt Service Routine). In OSE ISR's are known as interrupt processes and they execute (...) (25 years ago, 25-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) But hardware interrupts schedule a different context (the interrupt process or ISR) from the one already executing. A Unix-style signal asynchronously signal interrupts the executing process and jumps to a different location in the code that (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
32 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
