Thanks. First. I tried a bunch of different window managers across all
systems. And it either works on all of them (on the systems where it
works),
or on none of them. So not a WM issue.
> I would probably start by calling XSynchronize(dpy, 1) just after
> XOpenDisplay, to see if that changes where the hang happens.
>
Ah, I think I may know what the problem is, but not how to fix it.
Adding X changed where the hang happens, and now it is consistently
slightly earlier,
at a call to XCreateSimpleWindow
win->theWindow = XCreateSimpleWindow(win->theDisp, win->rootW, x, y,
w, h, bw, black, white );
But turns out that just before that call the library sets up and
starts a new thread (using pthreads) running the loop below, and I
think it's the thread that causes the deadlock.
TASKTYPE TASKMOD XEventThread(void *data)
{
XEvent xev;
HEventRec r;
HWin win;
HThread t;
do{
XNextEvent(globDisp, &xev);
r=convertXevToHEventRec(xev);
if(r.event != HIGNORE) {
win=FindWindowRec(xev.xany.window);
t=win->theThread;
postEventToQueue(t, r);
}
HFlush();
}
while(True);
}
Basically, it's taking up X events and re-posting them into queues
handled by the apps with the convertXevToHEventRec and
postEventToQueue calls.
If I disable the creation of that thread, nothing freezes anymore, but
the apps that depend on the library start misbehaving (e.g., windows
not reacting properly to close events).
I tried adding XLockDisplay/XUnlockDisplay around the calls to
XNextEvent, but that does not work because it blocks waiting for
events and the display is permanently locked.
Does this seem to be a likely diagnosis? If so, is there the correct
way to do this without causing the deadlocks but without losing the
basic idea that the library relies on (copying X events to an
app-specific queue)?
Myrosia
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
