<div dir="ltr">I don't see how that's the case. The select() call should never block, see:<br><br><a href="http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000">http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000</a><br><br>From select(2):<br><br>    If both fields of the timeval structure are zero, then select() returns immediately.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 7:18 PM, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13.05.2015 07:39, Daniel Drake wrote:<br>
> The X server frequently deals with SIGIO and SIGALRM interruptions.<br>
> If process execution is inside certain blocking system calls<br>
> when these signals arrive, e.g. with the kernel blocked on<br>
> a contended semaphore, the system calls will be interrupted.<br>
><br>
> Some system calls are automatically restartable (the kernel re-executes<br>
> them with the same parameters once the signal handler returns) but<br>
> only if the signal handler allows it.<br>
><br>
> Set SA_RESTART on the signal handlers to enable this convenient<br>
> behaviour.<br>
<br>
</span>The discussion about this on IRC sounded to me like we don't want to do<br>
this for both signals, because at least one of them should interrupt<br>
select(). My guess would be that SIGIO should interrupt select() and<br>
thus shouldn't use SA_RESTART.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Earthling Michel Dänzer               |               <a href="http://www.amd.com" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">  Jasper<br></div></div>
</div>