nanogui: Thread: thread-safe but not thread-able?

Hi,

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.

Is this intended?

With regards,

Thomas


Machen Sie aus 14 Cent spielend bis zu 100 Euro!
Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot.
http://www.arcor.de/rd/emf-gaming-1

> 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