[Xcb] [PATCH v2 2/2] Also signal special event waiters in _xcb_in_wake_up_next_reader

[Michel Dänzer]

On 10.06.2015 19:56, Uli Schlachter wrote:
> Am 10.06.2015 um 12:00 schrieb Michel Dänzer:
>> On 10.06.2015 16:32, Uli Schlachter wrote:
> [...]
>>> Alternatively, change the pthread_cond_signal() in event_special()
>>> to pthread_cond_broadcast() and see if that helps.
>>>
>>> (The idea being: There are multiple threads in xcb_wait_for_special_event()
>>> concurrently.)
> 
> ... the idea was for a case where multiple threads are stuck in
> xcb_wait_for_special_event(). My current understanding is that
> _xcb_in_wake_up_next_reader() is needed for a case where multiple threads are
> waiting for events, replies or special events. To you know if Mesa ever does
> this? For the same kind of event or for different ones?

Mesa doesn't spawn multiple threads processing X11 events by itself,
however, applications can use OpenGL from multiple threads concurrently
(like the glthreads Mesa demo), or use OpenGL in one thread and process
X11 events in another thread.


>> That doesn't fix the first problem described below.
> 
> I understand this as "this doesn't fix any problem", [...]

That's indeed what I meant.


>> As described in the commit log, the test case for this patch is a
>> different one: The Mesa demos program called glthreads, which creates
>> several threads rendering with OpenGL (to one separate window each)
>> concurrently.
>>
>> The problem fixed by this patch is that glthreads often hangs when
>> trying to quit by pressing the Escape key.
> 
> Is there any easy way to get glthreads on debian that doesn't involve building
> something "big" like all of mesa?

git clone git://anongit.freedesktop.org/mesa/demos
cd demos
./autogen.sh
make -C src/xdemos glthreads


> Does this hang have the same backtrace as what the example program demonstrates
> and that is fixed with patch 1: One thread stuck in _xcb_conn_wait() ->
> pthread_cond_wait and no other threads inside of libxcb?

No, here's the backtrace of the hanging threads:

Thread 2 (Thread 0x7f3bfa91f700 (LWP 13505)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f3c0058c219 in _xcb_conn_wait (c=0x24641d0, cond=<optimized out>, vector=0x0, count=0x0) at ../../src/xcb_conn.c:447
#2  0x00007f3c0058dbd9 in xcb_wait_for_special_event (c=0x7f3bf400130c, c at entry=0x24641d0, se=0x80) at ../../src/xcb_in.c:761
#3  0x00007f3c03458e3f in dri3_find_back (priv=0x7f3bf40008c0, c=0x24641d0) at ../../../src/glx/dri3_glx.c:1268
#4  dri3_get_buffer (driDrawable=<optimized out>, loaderPrivate=0x7f3bf40008c0, buffer_type=dri3_buffer_back, format=4098) at ../../../src/glx/dri3_glx.c:1294
#5  dri3_get_buffers (driDrawable=<optimized out>, format=4098, stamp=<optimized out>, loaderPrivate=0x7f3bf40008c0, buffer_mask=<optimized out>, buffers=0x7f3bfa91eb40) at ../../../src/glx/dri3_glx.c:1473
#6  0x00007f3bfe127d60 in dri_image_drawable_get_buffers (statts_count=<optimized out>, statts=<optimized out>, images=<optimized out>, drawable=<optimized out>) at ../../../../../src/gallium/state_trackers/dri/dri2.c:279
#7  dri2_allocate_textures (ctx=0x24cbd60, drawable=0x7f3bf40009f0, statts=0x7f3bf4001048, statts_count=2) at ../../../../../src/gallium/state_trackers/dri/dri2.c:402
#8  0x00007f3bfe123dbd in dri_st_framebuffer_validate (stctx=<optimized out>, stfbi=<optimized out>, statts=0x7f3bf4001048, count=2, out=0x7f3bfa91eca0) at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83
#9  0x00007f3bfe00dfde in st_framebuffer_validate (stfb=stfb at entry=0x7f3bf4000c00, st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:200
#10 0x00007f3bfe00fbc5 in st_manager_validate_framebuffers (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_manager.c:863
#11 0x00007f3bfdfc8e16 in st_validate_state (st=st at entry=0x2527a10) at ../../../src/mesa/state_tracker/st_atom.c:181
#12 0x00007f3bfdfd2821 in st_Clear (ctx=0x7f3c03cd7010, mask=18) at ../../../src/mesa/state_tracker/st_cb_clear.c:463
#13 0x00000000004025c7 in draw_loop (wt=0x604580 <WinThreads>) at glthreads.c:275
#14 thread_function (p=0x604580 <WinThreads>) at glthreads.c:526
#15 0x00007f3c029880a4 in start_thread (arg=0x7f3bfa91f700) at pthread_create.c:309
#16 0x00007f3c026b604d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f3c03d847c0 (LWP 13503)):
#0  0x00007f3c029894db in pthread_join (threadid=139895583667968, thread_return=thread_return at entry=0x0) at pthread_join.c:92
#1  0x0000000000401f4a in clean_up () at glthreads.c:541
#2  main (argc=<optimized out>, argv=<optimized out>) at glthreads.c:686


>> Another problem which I suspect might be related, but which isn't fixed
>> by these changes, is https://bugs.freedesktop.org/show_bug.cgi?id=90798
> 
> I have no idea how XCB could have anything to do with this, nor do I know how
> this could happen at all, sorry.

It's just a hunch, because the ingredients seem similar to the other
problems we're discussing here: Multiple threads, DRI3/Present, X11
events related trouble.


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