nanogui: thread-safe but not thread-able?
Subject:
Re: [nanogui] thread-safe but not thread-able?
From:
"Greg Haerr" ####@####.####
Date:
9 Jul 2005 15:25:02 +0100
Message-Id: <4bb801c58491$b91c6f60$6401a8c0@winXP>
> It seems there's a problem with multi-threaded environments. If there's
one thread in GrGetNextEventTimeout the global mutex is locked. If another
thread if calling any GrXXX function it is blocked because of calling
LOCK(nxGlobalLock) until an event arrives for the first thread.
Yes, the current design forces this to the be way this has to work.
The server hasn't been coded to worry about what might happen should
it fill an output queue for a given application with so many events that the
write blocks the server. So, instead, the GrGetNextEvent functions
pass a token to the server indicating that they are in fact ready
to read more events, thus avoiding the problem. Thus, the locking
required when in the GrGetNextEvent[Timeout] function.
Regards,
Greg
