 | | Re: signals / legOS internals —Ola Liljedahl
|
| | | (...) 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 (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | |
| | | | | Re: signals / legOS internals —John A. Tamplin
|
| | | | | (...) 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)
|
| | | | | |
| | | | | | | Re: signals / legOS internals —Ola Liljedahl
|
| | | | | | (...) 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)
|
| | | | | | |
| | | | | | | | Re: signals / legOS internals —John A. Tamplin
|
| | | | | | | (...) 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 —Ola Liljedahl
|
| | | | | | | | (...) In OSE interrupt processes (first class processes, that is why we don't call them ISR's) use OS mechanisms (usually messages) to communicate with normal processes. The OS handles all update of shared data structures (such as message queues). A (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —John A. Tamplin
|
| | | | | | | | (...) This is the same thing as most modern RTOS use, called various things. The terminology I use for this is FLIH/SLIH (first level interrupt handler and second level interrupt handler). Coupled with lock priority inheritance, it makes for a very (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Ola Liljedahl
|
| | | | | | | | (...) This second methed doesn't really solve anything since you still have to communicate with the compute thread from the receive thread. (...) But what can you actually do in the signal handler? Modify the state of the state of the executing (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | (...) 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)
|
| | | | | | |
| | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | | (...) 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 —Lou Sortman
|
| | | | | | | | (...) So, should I abandon my implementation? If something every bit as good is already there, it may be silly for me to continue. I haven't looked at Librcx yet, so I don't completely understand how it works. I think one of the original reasons for (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | | | (...) No, you should not abandon your implementation - not if you want to use LegOS. I was only explaining how I implemented similar functionality, for the sake of comparison. Regarding Librcx, I might release another version at some point, to add (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Lou Sortman
|
| | | | | | | | (...) Cool. I will proceed. (...) Yup. I was out of the loop for awhile, and am once again whompin' on this project. (...) That is true. Signals would give the task the opportunity to stop/start tasks under its control, though, without the task that (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | | | (...) What am I missing? Why do you need callbacks in the process structure? I was thinking if you can reference the thread, you can just call a system function (e.g. suspend(thread)), and that will suspend the thread. You do not need callbacks (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Luis Villa
|
| | | | | | | | | (...) Now keep in mind that this is coming from someone who won't take Duke's OS class until next spring- is there any reason the current semaphore implementation couldn't be used for a large percentage of these tasks? I.E., thread A checks (or uses (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | | |
| | | | | | | | | | | Re: signals / legOS internals —Lou Sortman
|
| | | | | | | | | | (...) They could. In fact, there may be cases where that is exactly what you want to do. However, that requires you to write your code to examine the semaphore at every point where you would want to consider processing the event. It is more work. (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Lou Sortman
|
| | | | | | | | (...) Yes, that is it. A classic example is a full screen app such as vi. When being stopped, vi sets the terminal mode to something generic and saves any screen info that it needs. When resumed, it sets the terminal mode back to what it wants and (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | | | (...) So is the idea that you might have a "shell" app that lets you control a button or two and that takes over the lcd at times (say), and lets you start, suspend, and stop other apps that control different, presumably disjoint sets of motors and (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | | | |
| | | | | | | | Re: signals / legOS internals —Ola Liljedahl
|
| | | | | | (...) 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)
|
| | | | | | |
| | | | | | | | Re: signals / legOS internals —Kekoa Proudfoot
|
| | | | | | 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: (...) (25 years ago, 25-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | Re: signals / legOS internals —Lou Sortman
|
| | | | (...) Because they are useful at times, and Markus directed me to implement them. I think the upcoming network code is going to use them, too (at least, that's what I heard). Just 'cause they're there doesn't mean you have to use them. (...) How do (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | RE: signals / legOS internals —Ralph Hempel
|
| | | | (...) Ummmmm, I don't want to speak for Markus, but most embedded kernels (and I use a lot of them) use the term signal and semaphore interchangably. I'm willing to bet a couple of bricks that the intent is to implement semaphores to facilitate (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: signals / legOS internals —Lou Sortman
|
| | | | I misspoke when I said before that we have semaphores. What I meant was mutexes. We have had mutexes for quite awhile. Certainly long before I started on this signal thing. I started this long enough ago that I don't remember what particular problem (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| | | | |
