From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32265 invoked by alias); 24 Oct 2008 14:14:07 -0000 Received: (qmail 32242 invoked by uid 22791); 24 Oct 2008 14:14:06 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Oct 2008 14:12:54 +0000 Received: (qmail 1292 invoked from network); 24 Oct 2008 14:12:52 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Oct 2008 14:12:52 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: generic async event handlers in the event loop, for remote non-stop (was: generic `struct serial' interface pipe for remote non-stop) Date: Fri, 24 Oct 2008 14:14:00 -0000 User-Agent: KMail/1.9.9 References: <200810240132.42007.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810241512.55053.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00607.txt.bz2 On Friday 24 October 2008 10:54:36, Eli Zaretskii wrote: > > From: Pedro Alves > > Date: Fri, 24 Oct 2008 01:32:41 +0100 > > > > signal handlers should keep the current behaviour of having high > > priority in relation to normal events > > I don't necessarily disagree, but can you explain why is that? Sure! But, do you see a case to change that established behaviour? We give them high priority (we delay signals until we get to the event loop, but handle them immediatelly once we get there, we don't delay them further) . That isn't appropriate for my event sources, as I explained before, so we can't have it both ways in a single mechanism. If we change signal handlers to have as much priority as normal event sources, then we risk the case were a signal handler is delayed further (and indefinitely, until some another signal arrives) due to entering a blocking call (like poll/select/wait etc.), due to handling some other event before the signal's turn in the event loop arrives. This current behaviour isn't super perfect, as the signal could be marked just before entering poll/select, but, that's the current behaviour, and should be fixed separately when there's a need. Lowering the signal handlers priority is a step in the wrong direction, IMHO. -- Pedro Alves