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

[Chase Douglas]

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. 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.

-- Chase