Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 15 Feb 2003 19:08:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 15 Feb 2003 19:08:20 -0500 Received: from almesberger.net ([63.105.73.239]:786 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id ; Sat, 15 Feb 2003 19:08:19 -0500 Date: Sat, 15 Feb 2003 21:18:08 -0300 From: Werner Almesberger To: Davide Libenzi Cc: Kernel Mailing List Subject: Re: Synchronous signal delivery.. Message-ID: <20030215211808.K2092@almesberger.net> References:

<20030215010837.D2791@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from davidel@xmailserver.org on Sat, Feb 15, 2003 at 02:00:05PM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1116 Lines: 26 Davide Libenzi wrote: > You could do that, even if when you start having many timers things might > get messy. Manage a list of pending timers, schedule a signal for the next one (or, if you wish, launch a thread), etc. All that is pretty standard stuff that can be hidden in some library function, and you can even steal a lot of the code from the kernel :-) It would be useful, though, to have something like the "overwrite" function I described later in this thread, in case there is a single fd that can accumulate more timer expirations between reads, than fit into the pipe/queue. (Admittedly a bit of a fringe scenario.) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/