Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753188Ab0DKWAb (ORCPT ); Sun, 11 Apr 2010 18:00:31 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:58558 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753161Ab0DKWA3 (ORCPT ); Sun, 11 Apr 2010 18:00:29 -0400 X-Greylist: delayed 474 seconds by postgrey-1.27 at vger.kernel.org; Sun, 11 Apr 2010 18:00:29 EDT X-AuthUser: davidel@xmailserver.org Date: Sun, 11 Apr 2010 14:52:12 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@makko.or.mcafeemobile.com To: Andi Kleen cc: Frantisek Rysanek , Linux Kernel Mailing List Subject: Re: setitimer vs. threads: SIGALRM returned to which thread? (process master or individual child) In-Reply-To: <87d3y5btdk.fsf@basil.nowhere.org> Message-ID: References: <4BBFA0C6.2610.2C4FFE@Frantisek.Rysanek.post.cz> <87d3y5btdk.fsf@basil.nowhere.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1399 Lines: 35 On Sun, 11 Apr 2010, Andi Kleen wrote: > "Frantisek Rysanek" 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. Definitely timerfd allows you to handle the timer event wherever you like, independently from signals. Much much simpler routing. But if you need to be compatible with multiple unixes, of even older linux kernel, you are out of luck with timerfd. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/