Why is XSetStandardProperties freezing?

[walter harms]

Am 21.06.2012 23:13, schrieb Myrosia Dzikovska:
> 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.
> 

You are quiet advanced with that, you should setup a bugreport
at opensuse: https://bugzilla.novell.com/index.cgi

there is also a special mailinglist for opensuse: opensuse-xorg at opensuse.org

hope that helps,
re,
 wh


> 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
> _______________________________________________
> xorg at lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: wharms at bfs.de
>