Re: signals/threads
- From: Jan Panteltje <pNaonStpealmtje@xxxxxxxxx>
- Date: Mon, 26 Dec 2005 11:59:11 GMT
On a sunny day (25 Dec 2005 21:41:00 -0800) it happened "Ask"
<ask.q@xxxxxxxxxxxxxx> wrote in
<1135575660.039750.152870@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>I was trying to implement a timer functionality -not sure its the right
>way to do it.
>A thread (timer task) listens to the incoming timer request and
>maintains a list of the
>same. Timer request also contains the callback function to be executed.
>The
>timer task is notified by the kernel (SIGALARM) at 'appropriate
>instants of time' ,
>and in the signal handler the callback function is executed.
>
>Now you see the problems
>-What if the callback function is blocking
>-What if the callback function is nonblocking but takes substantial
>amount of time to execute
>-What if the callback function uses semaphores
>- Also, change of priority during execution. The callback function was
>provided by the user task that had certain priority, but since it is
>now getting executed in the signal handler context, prority got
>changed.
What I have done is set flags, other threads monitor the relevant flags
and take then some action, and reset that flag.
The main (or in your case signal handler) will return immediatly.
You can complete the handshake by having the thread set an other flag on
completion, and have the main look for that (in a loop).
Main should not do anything else that takes lot of time.
Then the whole things becomes more of a states machine, states set by the flags.
You could assign states to one flag too.
It is actually a fun way to program, very flexible.
.
- References:
- signals/threads
- From: Ask
- Re: signals/threads
- From: Ask
- signals/threads
- Prev by Date: Static AND Dynamic linking at the same time
- Next by Date: Re: dynamic ELF -> static executable?
- Previous by thread: Re: signals/threads
- Next by thread: Patel
- Index(es):
Relevant Pages
|
