[Xcb] [PATCH] Fix a thread hang with xcb_wait_for_special_event()

[Uli Schlachter]

Pushed, thanks for investigating and testing.

Am 16.06.2015 um 04:10 schrieb Michel Dänzer:
> On 16.06.2015 02:45, Uli Schlachter wrote:
>> Am 15.06.2015 um 12:03 schrieb Michel Dänzer:
>>> On 12.06.2015 22:21, Uli Schlachter wrote:
>> [...]
>>>> +static void insert_special(special_list **prev_special, special_list *special, xcb_special_event_t *se)
>>>> +{
>>>> +    special->se = se;
>>>> +    special->next = *prev_special;
>>>> +    *prev_special = special;
>>>> +}
>>>
>>> AFAICT this inserts the new special_list entry at the beginning of the
>>> linked list, so the thread corresponding to the last inserted entry will
>>> be woken up first, right? It might be fairer to make this a FIFO instead
>>> of a LIFO.
>> [...]
>>
>> Hm. Yes, you are right. However, changing this either requires traversing the
>> linked list or adding a pointer to its tail. I don't really like either solution.
>>
>> This doesn't really matter for different xcb_special_event_t instances (we can't
>> predict which one gets an event next anyway and event_special() will wake up the
>> right one). If two threads call xcb_wait_for_special_event() on the same
>> xcb_special_event_t instance, then there is a race anyway and I don't really see
>> why we should guarantee anything at all. Also, I can't really think of any
>> reason to call xcb_wait_for_special_event() concurrently.
> 
> FWIW, I don't think there's anything preventing that from happening with
> DRI3 when using OpenGL from several threads, such as in the glthreads
> demo app.
> 
> Anyway, you've convinced me that the order in which these list entries
> are processed shouldn't matter much (more so since pthread_cond_signal
> doesn't wake up any specific thread but a random one waiting on the
> condition variable). The patch is
> 
> Tested-by: Michel Dänzer <michel.daenzer at amd.com>
> 
> 


-- 
Sent from my Game Boy.