[Bug 31882] Many multithreaded gui apps randomly deadlock in winex11 driver surface section (arial32.exe, Aquanox, Mahaa demo, Total Commander)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=31882

--- Comment #57 from Henri Verbeet <hverbeet at gmail.com> 2012-10-28 16:20:21 CDT ---
(In reply to comment #53)
> The problem is that you really do want to flush the surface before waiting on
> events.  You can't have unflushed drawing pending for indefinite periods,
> especially if the the user is supposed to be reacting to whatever is supposed
> to have been drawn.
I suppose you could flush before queueing the message if this is really an
issue, but it seems a bit questionable to me to flush on every wait_message()
in the first place. I'd imagine you only want to flush after specific events
like e.g. paints.

(In reply to comment #54)
> The only mechanism I can see is from the wineserver's
> kill_thread() sending SIGQUIT, causing (inside of ntdll) quit_handler() ->
> abort_thread() -> terminate_thread() -> pthread_exit().
> 
> Is that what's happening?
Yes. It's more or less equivalent to calling pthread_cancel() on the remote
thread, although pthread_cancel() is slightly nicer because it gives the thread
a chance to run its cancellation handlers. Calling pthread_exit() from the
signal stack would make that pretty hopeless as well, if anything actually had
cancellation handlers.

> I don't blame libxcb for failing to properly handle the case where a thread is
> unceremoniously terminated while within it.  It seems the Wine bug is that it
> needs to protect the libraries it uses -- at least libX11/libxcb -- from that
> sort of abrupt termination, I guess using signal handlers.  (Although such
> protection may be both impractical and would prevent proper termination of
> threads while they're blocked in library calls.)
No. TerminateThread() is unsafe in that regard on Windows as well. What's
different here is that the TerminateThread() call is actually the result of the
original thread sending some WM_USER message, so the thread that does the
actual TerminateThread() call knows the thread is supposed to be in a known
safe state. (I.e., it's just that anything we do between queueing a message and
waiting for its result has to be cancellation safe.)

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.