Am 21.06.2012 23:13, schrieb Myrosia Dzikovska:
> On Thu, Jun 21, 2012 at 3:07 PM, Adam Jackson <a...@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-x...@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@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: wha...@bfs.de
>
_______________________________________________
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
