From: Steve Cheng <elmert@ipoline.com>
  To  : GGI Mailing List <ggi-develop@eskimo.com>
  Date: Mon, 14 Sep 1998 19:29:07 -0400 (EDT)

Re: SYNC mode should go

On Sun, 13 Sep 1998 becka@rz.uni-duesseldorf.de wrote:

> Why doesn't it ? It ensures the screen gets updated at about max 50ms
> after the command complets - what's wrong with that ?

How do you know it's max 50ms?  Kernel scheduling is not exact.  Besides I'm
not sure if the time frame fits the definition of "immediate".
But there's really no point in arguing this point now...

> SYNC mode is there to avoid waiting for keystrokes while the menu is not yet
> drawn etc.

Ah, so it's now okay to use SYNC mode?  Mansync is quite unsafe when we
don't have the async-signal locks any more:

(in another message you suggested:)
> 2. Leave SYNC mode. If threads are enabled, we just use them, if not, we live
> with the possibility of a lockup or erratic behaviour. We can simply give
> a warning like: "SYNC mode is unsafe on this target - don't complain if it
> crashes".

I'd prefer to simply leave out mansync if the user did not compile with
threads and setting SYNC mode will fail, rather than have dangerous code
unknowingly used by applications (remember, they don't know whether the
underlying target is mansync-based or not!).  LibGGI should be compiled
with multithreading support anyways to do proper locking.

> And BTW: There are quite some shortcomings of ASYNC mode ...
> Try it under the X target. As LibGGI has no notion of an "Event-Loop"
> or something, an ASYNC application will not update correctly after
> it has been hidden by some other window.

The X target should emit an expose event that tells the application to do a
ggiFlush() or whatever.

--
Steve Cheng

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