nanogui: multi-threaded app: problem and suggestion; patch
Subject:
Re: [nanogui] multi-threaded app: problem and suggestion; patch
From:
"Greg Haerr" ####@####.####
Date:
23 Aug 2005 21:30:43 +0100
Message-Id: <056101c5a821$3dfe72c0$0300a8c0@RDP>
: The deadlock happens because in time of call GrNewWindow, GrNewGC, etc.
: (that do mutex lock) the mail_loop_func wait on select call inside same
: mutex lock.
Petr -
Thanks for the explanation. Note that you
MUST have GrFlush() before sleep(), which is not always
the case in your code, you might check this.
I think I understand your issue: when the mainloop is sitting
inside of GrGetNextEvent(), another thread runs, which
immediately waits in the same lock, until an event is received,
which may never happen. right?
If this is the case, it could be a serious issue, since unfortunately,
we can't tell whether we're receiving a server response back
from a request, or an event, when blocked waiting in
GrGetNextEvent. I'm thinking that the only real solution may be
as follows: only allow an "application" (group of threads) to
actually block when no thread will require further nano-X
calls other than GetNextEvent. But since we won't know this,
then we might have to force a event timeout return from
any thread waiting in GrNextEvent so that another request
can be sent to the server. But this will cause sync problems
in some cases with the server.
The current design always serializes ALL requests into a single-threaded
model with the server... or the server can get confused. And this is
why your second thread will have to wait until the first thread
actually gets an event... perhaps an application could set a timer
that would wakeup a blocked semaphore getnextevent every
once in a while, so that the system doesn't deadlock?
: The patch's part for case when nano-X server linked with application,
: really don't solve main problem. Ignore it in first approach. Now I have
: much better solution (but it essential multithreaded). I will send this
: suggestion a bit later.
I'll be interested to see the approach you take.
: What about external libs and gcc version patches?
they're fine, I'll be adding them unmodified to CVS.
Regards,
Greg
:
: Best regards,
:
: - ptr
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
:
