nanogui: multithreading issues
Subject:
Re: [nanogui] multithreading issues
From:
"Greg Haerr" ####@####.####
Date:
29 Aug 2007 20:14:34 +0100
Message-Id: <3e8e01c7ea70$b5a33fc0$0300a8c0@RDP>
> 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.
This can only work, even with your mod, only if you can guarantee
that no two threads will ever call a non-void GrXXX function
at once. If the other threads only call void GrXXX (drawing only)
functions, this likely will work, since essentially the client->server
communications is write-only.
> With those two patches both the case of Client/Server and
LINK_APP_INTO_SERVER should be covered.
At first glance, it seems OK, I need to think more deeply about
the locking mechanism and exactly when select() returns 0.
Can you send me your sample program that shows the system
not working until the patches are applied?
> 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.
I agree this is likely the answer, but the server will execute every
request on behalf of the calling thread, and that thread can't be
interrupted until the server's done processing it. I'm not sure
this can be guaranteed without more thought. Easier would be
to allow only non-voide Gr calls as discussed above. (perhaps we
need to put a list together of non-void drawing functions for
further analysis)
Regards,
Greg
