From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Sun, 13 Sep 1998 11:01:10 -0400 (EDT)

Re: SYNC mode should go

On Sat, 12 Sep 1998 mentalg@geocities.com wrote:

> > This does not save you the locking for all targets.

All of LibGGI is supposed to be thread-safe.  This is no different from
calling LibGGI functions in separate threads together.

Flushing on signals is a losing position, if someone wants to do it, let
him/her implement the signal mask stuff himself/herself.

> Nor should it.  But trying to lock around signal handlers gets _real_ ugly.
> We really just can't make LibGGI async-signal-safe as a whole, so if nothing
> else, the signal implementation of mansync _should_ be dropped.  A threaded
> mansync implementation doesn't really make locking any more complex than it
> should be normally.

Agreed.

But anyone thinks that the mansync SYNC system is fundamentally wrong -- I
mean, not just that it is bloat, overly complex, evil, etc. but that it does
not meet the definition of SYNC mode ?

  When the drawing command returns, it is already or will be
  executed very shortly. So the visible effect is that everything is
  drawn immediately.  (It is not guaranteed in the strict sense that it
  is already drawn when the function call returns, but almost.)

Flushing 20 times per sec from a separate thread,process,signals does not
guarantee this, nor should we (at least in theory) fool the application that
it is.  In other words, don't try to emulate it if it is not possible. 

(Note that X-lib target's SYNC mode is still alright, because in fact it
does synchronize after each operation.)

--
Steve Cheng

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