From: mentalg@geocities.com
  To  : andreas.beck@ggi-project.org
  Date: Sun, 13 Sep 1998 13:15:20 -0400 (EDT)

Re: Open list of issues before Degas goes out

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

> Hi !
> 
> > > > IMHO. Remove SYNC and place it in a extensions library. 
> > > 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?
> 
> Yes, but from what i read on the list, I got the impression, that people
> are trying to avoid the locking hassles, not so much the using of the
> mansync code.
> 
> And the locking cannot be avoided - mansync or not.

Indeed!  I was _never_ advocating ignoring the locking issues.

> What I wanted to avoid is somthing that would boil down to:
> 
> We drop SYNC mode for now, with the idea of re-adding it back later,
> and then, when SYNC mode is away, we get lazy, don't do proper locking,
> write a bunch of targets with that attitude and wonder lateron, why
> adding back SYNC is rather impossible.
> 
> Whatever we do, I want it to be done right. That is either we kill
> SYNC mode completely, so we can safely forget about the locking, or
> we do the locking right and keep it (maybe making ASYNC default).

We can't forget about locking even if we DO kill SYNC mode.  Except for
signal-safe locking, which is IMO just not worth the overhead.  (Even
pthreads doesn't pretend to be async-signal-safe -- i.e. sem_post() is the
_only_ async-signal-safe pthreads call)

> > > SYNC mode is not just another LibGGI call. If it is there, you need to
> > > take care of it in _EVERY_ target that isn't inherently synchronous.
> > That's actually all of them as far as I know, except maybe SVGALib.  (Think
> > accels). 

> KGI and probably fbcon are, too as it is now. However this will change.

Right.  So we are eventually going to need mansync for SYNC mode on every
target but SVGALib... think about that a second.  SYNC mode and mansync may
not be the same, but SYNC will basically be entirely dependent on mansync.

> > And it basically is just another library call:  ggiFlush(), called
> > regularly.
> 
> Yes - but a call that needs to be callable in a thread/signal-safe way.

All of the calls should be threadsafe.  However, I've come to the conclusion
that making the LibGGI calls async-signal-safe just isn't worth it -- you
take a pretty big performance hit from setting the signal mask, not to
mention that manipulating the signal mask from inside the library gets
messy.

IMO, general-purpose libraries should almost NEVER directly interact with
signals or signal masks, as it is too hard (impossible?) to completely
anticipate/work around the needs of the application programmer.

> > Right.  i.e. call ggiFlush() at regular intervals from another thread, which
> > goes real easily in a small extension library.
> 
> Yeah - so why remove it at all ? Just because the signal-method is ugly ?

Yes, since the signal method is the _only_ way we can to do it without
USE_THREADS.  Now, if we were to make libggi always require pthreads...
(actually, that's not quite so farfetched, as most systems have something
availible that is, or could be wrapped to look like, pthreads)

-=MenTaLguY=-