nanogui: multi-threaded app: problem and suggestion; patch
Subject:
Re: [nanogui] multi-threaded app: problem and suggestion; patch
From:
Petr Ovtchenkov ####@####.####
Date:
24 Aug 2005 07:48:51 +0100
Message-Id: <200508241014.14911.ptr@island.plnet.ru>
On Wednesday 24 August 2005 00:28, Greg Haerr wrote:
> : 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.
May be---this isn't real code just problem simulator (but one is derived
from real code).
>
> 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?
Yes.
>
> 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?
I.e. problem that there are sync and async events, that processed in the same
manner. Hmm, problem really deepper than I expected.
Best regards,
- ptr
