Re: signals/threads
- From: "Ask" <ask.q@xxxxxxxxxxxxxx>
- Date: 25 Dec 2005 21:41:00 -0800
>In most cases the number of signals doesn't matter anyway, so you
>probably don't need to worry about that last part of it.
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.
Is such implementation recommended ? Could you pls suggest some
pointers on how to do it. Is there any standardized way to implement
timers on linux.
Thanks
.
- Follow-Ups:
- Re: signals/threads
- From: Jan Panteltje
- Re: signals/threads
- References:
- signals/threads
- From: Ask
- signals/threads
- Prev by Date: disable typeahead / input queue w/ ncurses
- Next by Date: dynamic ELF -> static executable?
- Previous by thread: Re: signals/threads
- Next by thread: Re: signals/threads
- Index(es):
Relevant Pages
|