Why is XSetStandardProperties freezing?

[Myrosia Dzikovska]

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