nanogui: multithreading issues
Subject:
multithreading issues
From:
####@####.####
Date:
29 Aug 2007 14:58:45 +0100
Message-Id: <20070829085810.4mmuxhgxq84gsoog@localhost>
Hi,
Going through various emails from this list and experiments I'm trying
to find a way to have one thread dealing with events and many other
threads calling GrXXX functions. To my defense I can only say, that
it's not me creating those threads, but some evil application
programmers;) I'm just trying to provide the graphics framework based
on nano-X.
The experiments have been conducted on an X86 with framebuffer support
and microwindows from CVS and of course THREADSAFE=Y.
Here are my observations:
1.) There is a deadlock both with LINK_APP_INTO_SERVER and without.
Create a thread, which calls GrGetNextEvent() and tell it to listen
only to keyboard events, but you never press any key.
GrGetNextEvent() takes a global lock and since select() never returns
no other thread can draw at the same time, although I don't see any
reason why this should be forbidden.
I propose two patches, which temporarily unlock the global lock in
case there are no events in the event queue, i.e. select() is
blocking, and lock it immediately after select(). (Please see files
attached)
With those two patches both the case of Client/Server and
LINK_APP_INTO_SERVER should be covered.
Greg, do you see any problems there?
2.) From what I saw the fun with multi threaded problems starts, when
there are non void GrXXX functions called, which means, that the
server needs to return something and its replies can get mixed up for
the client threads.
The solution to this problem should be to use LINK_APP_INTO_SERVER, so
there is no funny communication between client(s) and server, but
there are direct function calls instead.
Greg, would you consider to use LINK_APP_INTO_SERVER and the attached
patches as a safe approach for the described multi threading scenario?
Regards,
Robert
[Content type text/x-csrc not shown. Download]
[Content type text/x-csrc not shown. Download]
