On Aug 5, 2012, at 23:18, Peter Hutterer <[email protected]> wrote:
>> Overall, this change seems very fragile.
>>
>> OsReleaseSIGIO and OsBlockSIGIO are well balanced. I think a safer fix
>> would be to change OsReleaseSignals().
>
> unfortunately, the problem is not with OsReleaseSignals(), the problem is
> OsBlockSIGIO(), which only looks balanced. when OsBlockSIGIO() is called
> from within the signal handler, SIGIO is already in the sigprocmask, and
> that must not be undone by the matching OsReleaseSIGIO(), even if the count
> reaches zero.
>
> For all other signals, this works because we remember the mask and re-apply
> it. For SIGIO, it is simply unblocked. My patch would simply align the sigio
> code with the other code, the functions are largely identical after.
>
>> void
>> OsReleaseSignals(void)
>> {
>> #ifdef SIG_BLOCK
>> if (--BlockedSignalCount == 0) {
>> sigprocmask(SIG_SETMASK, &PreviousSignalMask, 0);
>>
>> #ifdef SIGIO
>> OsReleaseSIGIO();
>
> with this code, you'd get a SIGIO here, leading to the same bug.
Gah... yeah... blech...
Reviewed-by: Jeremy Huddleston Sequoia <[email protected]>
Although I am 90% certain this is going to come back and bite us some day...
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
