 | | Re: Implementation of Installable Timers —Joseph Woolley
|
| | | 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 —Iain McInnes
|
| | | | (...) 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 —Joseph Woolley
|
| | | | (...) 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 —Iain McInnes
|
| | | | (...) 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)
|
| | | | |
