[Mesa-dev] threads and X.org/AIGLX drivers

[Kristian Høgsberg]

On Wed, May 11, 2011 at 2:53 AM, Dave Airlie <airlied at gmail.com> wrote:
> Hey,
>
> So we got a bug reported against F15 where we were getting an illegal
> input event type 0, after passing it around the RH X team I eventually
> came to look at it.
>
> The problem appears to be that we are using llvmpipe as our swrast
> renderer and on systems that fallback to that we end up with threads
> inside the X server, that we didn't spawn. It appears SIGIO gets
> delivered to one of these threads while the main thread keeps on
> trucking and fail ensues.
>
> So I'm crossposting this as there are two fixes we can do that aren't
> exclusive but could act as belt and braces on Linux at least (other
> OSes get the belt only).
>
> Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging
> up this nugget, "From  Linux  2.6.32 onwards, use F_SETOWN_EX to
> target SIGIO
>                and SIGURG signals at a particular thread.". So on
> Linux we would use that instead of F_SETOWN to make sure SIGIO only
> goes to the main X process/thread. Though I'm not sure how to get the
> defintion for gettid which we need, though I'll look into this a bit
> more.
>
> Fix 2: block all signals in the gallium thread spawning code, this
> involves using pthread_sigmask around the pthread_create function.
> Calling it once with a full set of signals to block, and get a copy of
> the current signals, then calling it again to put back the current
> signals. I think this might be a good plan for some other things, as I
> can't see a good reason for a DRI driver to ever get SIGIO, esp as it
> may interfere with the parent app.
>
> I've built a test package with 2 in it for Fedora and am awaiting
> feedback from the tester, but just though I'd raise the subject here
> for some discussion/feedback.

A different solution could be to use the input thread idea and stop
taking SIGIO.

Kristian