nanogui: multi-threaded app: problem and suggestion; patch
Subject:
Re: [nanogui] Re: multi-threaded app: problem and suggestion; patch
From:
"Greg Haerr" ####@####.####
Date:
24 Aug 2005 04:55:58 +0100
Message-Id: <066b01c5a85f$9d971190$6401a8c0@winXP>
: remind me why the blocked thread needs to hold a lock?
The blocked thread may be blocked waiting for a response
from the server from say, GrGetScreenInfo, and at that
point the server must stay sync'd with the client: if the
client thread weren't locked, and another thread proceeded
to send another request to the server that needed a response,
it would get the response intended for the first thread.
The other case is slightly different, which is when a
thread is not waiting for an api response, but is waiting for
an event from the server. In this case, the server code handles
things just a bit differently, and the server sends an
event record to the client. The problem is, that
the line protocol isn't currently designed to show
the difference between different response types
from the server. Thus, if the server has an event
for a client, but instead is servicing a client api that
requires a response instead, it must queue the event
and wait for a request from the client asking for
an event.
This probably should be redesigned, in retrospect,
to best handle async events and responses from
client api requests. However, this brings about the
problem of event and api synchronization, and if
you look at the Xlib code that handles this, you'll
see its a complex mess, requiring sequence numbers,
dynamic queuing, and all sorts of fun stuff.
Regards,
Greg
