Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 25 Jun 1999 17:36:15 GMT
|
Viewed:
|
1135 times
|
| |
|
|
Ola,
I do not see why you persist. I understand that a signal handler is very
low level, that it is difficult to use right, that it only allows some
things and not others, unless you're very careful. But you still missed my
point, which was this: the signal mechanism is not for the feint of heart,
it is not for the beginning user, it is not necessarily the end-user's API;
it is a hook you can use to run code when a certain event occurs, and the
reason it is at such a low-level is to minimize cost. A related idea is
that you can extend the signal mechanism at a low relatively cost. Other
event notification methods would be more expensive in the first place, and
also more expensive to extend.
I never said what you apparently see as the be-all-and-end-all interface
for event notification (read: OSE processes) was bad in any way. In fact,
my feeling about this sort of thing is that if you want to use that sort of
notification, you should implement it. And perhaps even the lower-level
interface (read: the signal mechanism we are discussing) is flexible enough
for you to implement that. Or maybe not, in which case maybe LegOS is
missing other primitives that should also be added.
-Kekoa
|
|
Message is in Reply To:
 | | 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)
|
32 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
