On Mon, 2004-07-12 at 20:33, Stefan Holst wrote:
> hi again!
>
> thanks owen for the fast answer to my last question :)
>
> i just ran into another problem which may be gtk-related. one thread of
> my app runs
>
> gdk_threads_enter();
> gtk_main();
> gdk_threads_leave();
>
> to run a gtk window. another thread runs an independent xlib-event-loop
>
> while (this->keep_going) {
> XEvent event;
> XNextEvent (this->display, &event);
> /* ... */
> }
>
> to run some stock xlib-windows (the gtk-stuff is optional in my app, so
> i want to keep the code separate). the display used in this loop was
> opened by XOpenDisplay, after XInitThreads().
>
> most of the time the whole app runs fine, but in some rare cases
> XNextEvent stops receiving events and blocks. the gtk-window is still
> responsive at this time. this xlib-event-loop-freeze is a sort of a
> race condition since it cannot be reproduced deterministically.
>
> so i'm wondering, if it is theoretically possible that this race
> condition is between the event-threads of gtk and xlib. i didn't managed
> to reproduce this deadlock without a gtk-event-loop running.
>
> thanks in advance for any hints.
The X locking is internal to Xlib, so no, I don't think it's likely
that it has anything to do with the GTK+ code. We've seen previous cases
where the X-level locking was wrong in some of the X extension libraries
used by GTK+, so it's possible that it is something like that.
You do need to call XInitThreads() before gtk_init() if you are
operating in that mode.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part