Re: generic async event handlers in the event loop, for remote non-stop (was: generic `struct serial' interface pipe for remote non-stop)

[Pedro Alves <pedro@codesourcery.com>]

On Friday 24 October 2008 10:54:36, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > 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