Why is XSetStandardProperties freezing?
Myrosia Dzikovska
myrosia at gmail.com
Thu Jun 21 14:13:54 PDT 2012
On Thu, Jun 21, 2012 at 3:07 PM, Adam Jackson <ajax at redhat.com> wrote:
> On Thu, 2012-06-21 at 13:08 +0100, Myrosia Dzikovska wrote:
>
>> 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.
>
> Do you mean you halt in XLockDisplay, or in XNextEvent? If the former,
> then xlib is probably already locked by another thread. If the latter,
> then perhaps you didn't call XInitThreads, or didn't call it early
> enough.
>
> Alternatively, the OSes you're comparing may not have identical versions
> of libX11 and libxcb, and the failing one is missing a thread-safety
> fix.
Sorry, I wasn't clear enough. This is what appears to be happening.
On the OS that does not work (OpenSuse 12.1)
1. XInitThreads is called
2. A thread ("XEventThread") created by the library and starts executing
3. XEventThread calls XNextEvent
4. XNextEvent blocks waiting for events; it does not return
immediately because there are no windows yet
5. XEventThread releases control to the main app thread
6. the main app thread calls XLockScreen
7 the main app thread starts creating windows
8. The first call to X functions, e.g. XCreateSimpleWindow, hangs
This is with XSyncrhonize enabled; if it is disabled, a few X calls
will succeed, but eventually something will hang forever.
On the OSes that work (FC13, ScientificLinux 6) the difference is
point 8 - the calls to X never lock, everything proceeds happily.
I cannot call XLockScreen on the XEventThread because this creates a
deadlock with the main app thread while it's sitting there waiting.
Would this be evidence for your last suggestion, that OpenSuse libX11
or libxcb are missing some thread safety fix? Or is this bad X
synchronization and it would eventually break on a different OS as
well? I am not entirely clear if every call to X has to be locked or
not, and what to do with the blocking XNextEvent in that case.
If it is the former, then I need to figure out what to report to
OpenSuse; if this is the latter, I need to figure out if there is a
way to make it thread safe (not my design idea, but this is very core
to the library, so I need to see if I can salvage it without getting
into a big "re-write the whole library" deal).
Myrosia
More information about the xorg
mailing list