Subject:
|
Re: Implementation of Installable Timers
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 9 Jan 2004 16:58:23 GMT
|
Viewed:
|
3672 times
|
| |
|
|
Iain McInnes wrote:
> In lugnet.robotics.rcx, Joseph Woolley wrote:
>
> > 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 list?
>
>
> 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 calling a function from the killall() routine to unlink all of the timers. I
> could get away with this, because I haven't put any of the system timers on the
> list yet. A proper implementation would clean up after a rogue application, but
> still leave the system timers intact.
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.
>
> > Which version of BrickOS are you working with?
> > You may be able to use:
> > ENTER_KERNEL_CRITICAL_SECTION();
> > LEAVE_KERNEL_CRITICAL_SECTION();
> > instead of disabling interrupts.
>
>
> I'm using 0.2.6.10 - I've just had a look at the code, and yes, I think that I
> could use those functions.
>
> I'll gather the files, include some test files and apps, and mail them to you.
I looked quickly this morning at the code. Good implementation.
I did see one instance of an assignment within an assert(...) probably
should be changed.
Maybe a recurring timer should reinsert itself, thus removing that logic
from the tick code (gives control to the timer function). Perhaps, the
timer func could return a value indicating reinsertion (-1 = no, >= 0
specifies the time)
// Joe
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | 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)
|
5 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
|
|
|
|
