Messages in this thread | | | Date | Mon, 12 Apr 2010 00:09:59 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: setitimer vs. threads: SIGALRM returned to which thread? (process master or individual child) |
| |
On Sun, 11 Apr 2010, Andi Kleen wrote:
> "Frantisek Rysanek" <Frantisek.Rysanek@post.cz> writes: > > > Yes, it used to be quite a relief to have Linux do the management of > > timers for me. Now I have two options to choose from: > > 1) write my own "timer queueing" (timekeeping) code to order the > > timers for me in the master thread > > 2) find another function, similar to setitimer(), that would function > > the way setitimer() used to work in the old days... > > POSIX timers (timer_create et.al.) allow specifying the signal. > > So if you use custom RT signals for each threads and block them in the > threads you don't want them it should work. This would limit the > maximum number of threads though because there's only a limited > range of RT signals. > > There are probably other ways to do this too, e.g. with some clever > use of timerfd_create in recent kernels. > > Or you could overwrite the clone in the thread library to not > set signal sharing semantics. This might have other bad side effects > though.
Nonsense. Just use the right flags when creating the posix timer. posix timers support per thread delivery of a signal, i.e. you can use the same signal for all threads.
sigev.sigev_notify = SIGEV_THREAD_ID | SIGEV_SIGNAL; sigev.sigev_signo = YOUR_SIGNAL; sigev.sigev_notify_thread_id = gettid(); timer_create(CLOCK_MONOTONIC, &sigev, &timer);
That signal for that timer will not be delivered to any other thread than the one specified in sigev.sigev_notify_thread_id as long as that thread has not exited w/o canceling the timer.
Thanks,
tglx
| |