 | | Implementation of Installable Timers
|
|
Hello everybody. I have an implementation of installable timer handlers, and I’d like to solicit some feedback. This is definitely a facility that I’d like to see in BrickOS. The implementation doesn’t have to be my one. But I thought that I’d just (...) (21 years ago, 8-Jan-04, to lugnet.robotics.rcx)
|
| |
| | Re: Implementation of Installable Timers
|
|
Iain McInnes wrote: [snip] (...) Great idea! (...) In your implementation, would it be possible for the client task to be killed (in the case of a run-away task)... causing the struct to be deallocated... while the struct is still in the linked (...) (21 years ago, 8-Jan-04, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Implementation of Installable Timers
|
|
(...) You are right. I found in an app that I was using that if I pressed the run / stop button, my task would be killed, and leave a dangling timer - which would usually blow the little brick into the weeds :o) I 'solved' it in a crude way by (...) (21 years ago, 9-Jan-04, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Implementation of Installable Timers
|
|
(...) It would seem reasonable to check the location of the struct; if in kernel memory, don't remove; if in user memory, remove. However, you could add a flag to the timer struct which could use T_KERNEL and T_USER flags. (...) I looked quickly (...) (21 years ago, 9-Jan-04, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Implementation of Installable Timers
|
|
(...) I'd go with the flag, myself. (...) Its certainly possible for the client timer to reinsert itself - therefore the recurring timer is not strictly required. It could be left out for space reasons. I'd probably either take it out and make it (...) (21 years ago, 10-Jan-04, to lugnet.robotics.rcx.legos)
|
