Subject:
|
Re: signals / legOS internals
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 23 Jun 1999 19:42:40 GMT
|
Viewed:
|
1027 times
|
| |
|
|
"John A. Tamplin" wrote:
>
> On Wed, 23 Jun 1999, Ola Liljedahl wrote:
>
> > Why signals?!?
> >
> > Unix-style asynchronous signals is the last feature I would
> > ever want to implement or use. Brain-dead and very dangerous
> > "feature". As you write; "The problem is that a signal can
> > happen at any time". You shouldn't pass this problem on to the
> > application writer, it should be handled in the kernel and
> > reliable (synchronous) mechanisms (for instance semaphores,
> > message queues or OSE style message passing) should be presented
> > to the application.
>
> An asynchronous signal models a hardware interrupt. There are times when
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.
> that is the appropriate interface. There are times when other interfaces
> are less error prone and are easier to write correctly. Frequently using
> only synchronous communication involves creating additional buffer threads.
I did not mean synchronous communication between different processes
(or threads). I mean that the effect on the receiving process is
synchronous to that process (i.e. the effect is noticed when the
receiving process wants to see this effect). IPC can still be
asynchronous, i.e. process A can send a message to process B
without them being synchronized but process B will not detect
this event until it tries to receive that message. Process B is
not asynchronously affected by the message sending. This as a
contrast to process A Unix-signalling process B where B is affected
regardless where it is executing.
> The additional overhead for such an approach is not always justified.
I agree but this is not the problem here.
--
Ola Liljedahl
|
|
Message has 2 Replies:
 | | Re: signals / legOS internals
|
| (...) An ISR can certainly modify data that is used by the executing code. For example, if it doesn't save registers that are used the interrupted code will certainly be affected. In fact, the ISR is of little use if it doesn't modify data that can (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
| | | Re: signals / legOS internals
|
| (...) 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 (...) (25 years ago, 24-Jun-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: signals / legOS internals
|
| (...) An asynchronous signal models a hardware interrupt. There are times when that is the appropriate interface. There are times when other interfaces are less error prone and are easier to write correctly. Frequently using only synchronous (...) (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
|
|
|
|
