[PATCH 0/3] Make timers even more resistant to signals

[Peter Hutterer]

On Wed, Oct 03, 2012 at 12:26:54PM +0800, Daniel Kurtz wrote:
> On Wed, Oct 3, 2012 at 11:25 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> >
> > On Fri, Sep 28, 2012 at 01:25:50AM -0700, Keith Packard wrote:
> > > Peter Hutterer <peter.hutterer at who-t.net> writes:
> > >
> > > > Thanks, merged this into my tree. This should fix the remaining issues we're
> > > > seeing with synaptics.
> > >
> > > Did you see my comments about this patch? I'm really not excited about
> > > adding 12 more syscalls per WaitForSomething invocation. Seems like
> > > there are two options to fix this 'correctly':
> > >
> > >  1) Have the synaptics driver modify the timer interval from either a
> > >     wakeup or block handler as appropriate.
> >
> > A quick git grep shows that timers are used in keybard, mouse, joystick,
> > synaptics, and wacom, all of those are in the signal path. We could in
> > theory fix up the lot, but it will take time.
> >
> > >  2) Provide a signal-safe timer value setting function in DIX. This
> > >     would set a global flag indicating that 'something' changed in the
> > >     timers. WaitForSomething could use this flag to check whether the
> > >     timers need fixing before computing the timeout value for select.
> >
> > > At the very least, the server should only be blocking SIGIO and not all
> > > signals; that's half the syscalls...
> >
> > Both of these solutions seems to be more straightforward. Daniel?
> 
> 
> Blocking only SIGIO is very straightforward.
> The only reason I didn't do that is that the earlier patch used
> OsBlockSignals().
> 
> Peter: Any reason you did that instead of xf86BlockSIGIO()?

At the time OsBlockSIGIO() didn't exist yet and calling xf86BlockSIGIO()
from the DIX is a no-go. No reason it can't be changed now though to just
block SIGIO.

Cheers,
   Peter