[PATCH v2 00/14] Fix signal-unsafe logging

[Peter Hutterer]

On Fri, Apr 13, 2012 at 09:33:38AM -0700, Chase Douglas wrote:
> On 04/13/2012 01:34 AM, Daniel Kurtz wrote:
> > On Fri, Apr 13, 2012 at 9:09 AM, Peter Hutterer
> > <peter.hutterer at who-t.net> wrote:
> >> On Wed, Apr 11, 2012 at 06:33:26PM -0700, Chase Douglas wrote:
> >>> On 04/11/2012 04:53 PM, Peter Hutterer wrote:
> >>>> On Mon, Apr 09, 2012 at 11:17:26AM -0700, Chase Douglas wrote:
> >>>>> This new patch set includes a few fixes to the first and many more fixed
> >>>>> logging paths. All paths in the server that occur when it encounters a
> >>>>> fatal signal are now handled properly.
> >>>>>
> > 
> > Hi Chase,
> > 
> > I just started looking at the os/log.c in the X server again to fix an
> > unrelated issue, and realized that my patches from last year did not,
> > in fact, make logging safe to do from signal handlers.  I am really
> > glad you are looking into fixing this!
> > 
> > However, I have a more basic question.  Why does the X server process
> > input events in signal handlers the first place?
> > Why not just add the event device files to a read file set in the main
> > "WaitForSomething" select loop, and then call the appropriate driver
> > ReadInput from normal process context?
> > 
> > The X server must be using SigIO for some really good reasons, what are they?
> 
> To reduce input visual latency. Signal handlers are run immediately when
> the signal occurs. The process is interrupted no matter where it is,
> including when it is 500 stack frames deep from the event loop.
> 
> The reduced latency is an effect that some people don't notice, some
> people notice but it's not a big deal, and some people can't live
> without, based on what I remember from a discussion at XDC 2010. 

yes, that's the reason. pointer movement should be instantaneous (or closest
thereof) when moving the device. 

the whole thing exploded because it went from 
input event -> move the cursor

to

input event -> emulate or filter buttons if needed, interpret touch gestures, rescale to screen area
depending on current multiscreen setup, pointer acceleration, emulate scroll events
if applicable -> move the cursor

except for the last, they all need to be in that path since, you can't
really move the cursor until you know where to move it to.

> At that
> time, some devs from Nokia were looking at changing the signal context
> to a pthread, but I guess it stalled. I haven't heard anything about it
> for quite some time.

I remember two problems with it: the input thread was to big to prevent it
from being swapped out (and thus lose the response times). Not sure if that
was still a problem in the last set of patches.

The bigger problem was the input event generation code doesn't lock properly
because it expects to never be interrupted.

The last messages I can find on it are from Aug 2010, maybe Tiago has some
updates.

Cheers,
  Peter