lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 12 Apr 2010 00:09:59 +0200 (CEST) From: Thomas Gleixner <tglx@...utronix.de> To: Andi Kleen <andi@...stfloor.org> cc: Frantisek Rysanek <Frantisek.Rysanek@...t.cz>, linux-kernel@...r.kernel.org 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@...t.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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists