nanogui: multi-threaded app: problem and suggestion; patch
Subject:
Re: [nanogui] Re: multi-threaded app: problem and suggestion; patch
From:
Petr Ovtchenkov ####@####.####
Date:
24 Aug 2005 21:29:54 +0100
Message-Id: <200508250029.24780.ptr@island.plnet.ru>
On Wednesday 24 August 2005 07:55, 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.
>
> 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.
Greg,
What client functions assume synchronous communication with server, like
GrGetScreenInfo?
- ptr
