Subject:
|
Re: Implementation of Installable Timers
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 9 Jan 2004 09:39:48 GMT
|
Viewed:
|
3370 times
|
| |
|
|
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.
>
> 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.
Cheers.
Iain.
|
|
Message has 1 Reply:
 | | 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 (...) (20 years ago, 9-Jan-04, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
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
|
|
|
|
