nanogui: multi-threaded app: problem and suggestion; patch
Subject:
Re: [nanogui] Re: multi-threaded app: problem and suggestion; patch
From:
"Aaron J. Grier" ####@####.####
Date:
24 Aug 2005 20:57:51 +0100
Message-Id: <20050824195721.GH13075@mordor.unix.fryenet>
On Tue, Aug 23, 2005 at 09:55:05PM -0600, Greg Haerr wrote:
> : 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.
I assume nothing should be blocking inside GrGetScreenInfo()...
> 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.
I'm just wondering aloud why the lock has to be aquired by a client
before it blocks. it would make more sense for the client to acquire
the lock AFTER it's been unblocked but before it reads the event from
the server's queue, but I guess that depends on what events are coming
back...
> 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.
that's further down the road. (: seems like there's plenty that could
be done short-term to get the server-end better behaving with threaded
clients.
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
