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

Re: Open list of issues before Degas goes out

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

> > I should really stop this talk about putting SYNC mode somewher in an
> > extension or a target or ... .
> 
> Why not?  Is mansync (at least) really much more than calling ggiFlush() at
> regular intervals?

Nope.  Most of the code there is managing processes, signals (so it will
(hopefully) work if you have two mansync visuals at one time..)

Also, please don't confuse between SYNC mode and mansync.  Mansync is a
periodic flushing mechanism for inherently async targets.  SYNC mode that is
inherently supported should be o.k., but not mansync.

> expensive under many UNIXes.  It's bad enough that mansync takes over
> SIGALRM.

No, usually it uses a process + SIGPROF.  Not that it's not bad enough
already...

> > You can't just have some extension that spawns off a thread calling
> > ggiFlush().

Not really an extension, because it does not need to know about LibGGI
internals at all.

> That's exactly what I was suggesting.  ...and _almost_ exactly what the
> pthread implementation of mansync is, except it's loaded as a helper
> library instead of an extension.

It's a hack.

> > And you need real asynchronous behaviour for ggiFlush() to emulate the
> > behaviour of a synchrnous target. Just doing something like setting
> > a flush_needed flag (like Linux setting need_resched) and testing it in
> > LibGGI calls won't cut it, as e.g. ggiPuts("My question ?");select(..);
> > would break as the system is in a blocking select() and no LibGGI function
> > gets called, though the question isn't yet displayed.

Oh, so you want mansync to do this too?  I don't think libGGI should be
bloated with this stuff too.

> > X sync mode and GGI sync mode are _VERY_ different animals. X sync mode
> > is effectively {ggiDrawSth();ggiFlush;}. This crawls. Think of someone
> > drawing pixel-by-pixel.

That's REAL SYNC mode.  Mansync is NOT real SYNC mode.  It does not
guarantee anything other than an illusion of SYNC mode.

And yes, X-lib's SYNC mode crawls, that's why we recommend ASYNC mode for
everything.  The logical conclusion is that why we suffer so much pain to
emulate SYNC mode.

> > To do away with the two most annoying things about the mansync hack, we
> > could just introduce an envvar GGI_MANSYNC="SIGNAL_TO_USE[:frames/sec]".

The other annoying thing is that mansync is flaky at best.  I've seen demo
crashing unexpectedly with protocol errors at start quite a number of times,
probably because the lock is not safe.

--
Steve Cheng

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