From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 14 Aug 1998 20:13:52 -0400 (EDT)

Re: Extreme coolness and Re: helper-mansync continued...

On Fri, 14 Aug 1998, Marcus Sundberg wrote:

> Well, the only X calls that are made (except when setting modes) in the
> X-target are the ones in ggiFlush() and mansync is ignored while the
> handler calls ggiFlush().

Not really.

ggiUnmapPixel calls XQueryColor. (Not locked at all!)
ggiEventPoll calls XNextEvent, etc. (this is locked though)

> But wait... demo.c does ggiFlush() itself even though it's in SYNC mode,
> what if it recieves a sync-signal while in there?
> 
> Checking...
> 
> Nah, disabling mansync in the X-target's ggiFlush doesn't help, sigh...
> Dunno what the problem is then.

I tried disabling event handling, ggiFlush and X's unmappixel (using
generic-color instead) and there's no problem with demo any more.

Of course, tile in db mode isn't affected because tile sets async on its
tiles.  In theory, non-db mode should have caused problems too, but normal
runs probably don't trigger that sort of access patterns as with multi
target.  (Meanwhile there is a divide-by-zero somewhere when running demo in
tile non-db mode...)

I'll try making X target use a global lock[*] (i.e. static variable in the
display-x)...

Anybody know just how much threadsafe the average Xlib is?  If one process
opens multiple connections: app flushes visual A, and signal handler flushes
visual B, is that guaranteed to work?  But then we shouldn't assume a
threadsafe Xlib and should lock everything, right?

[*] mutex's are safer, I'll do those instead of ints if defined(USE_THREADS).

[2] Should we try to make libggi thread safe?  It's a lot of trouble and
affects performance.  Drawing with separate threads is never a good idea
anyway.

--
Steve Cheng               

email: steve@ggi-project.org   
www: <http://shell.ipoline.com/~elmert/>;