From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Sun, 13 Sep 1998 20:33:34 +0200 (MEST)

Re: Open list of issues before Degas goes out

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.

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).

> > 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.

> 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.

> 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 ?

CU,ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =