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

[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>


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer