From: mentalg@geocities.com
  To  : andreas.beck@ggi-project.org
  Date: Sat, 12 Sep 1998 15:11:25 -0400 (EDT)

Re: Open list of issues before Degas goes out

On Sat, 12 Sep 1998 becka@rz.uni-duesseldorf.de wrote:

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

> 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).  And it basically is just another library call:  ggiFlush(), called
regularly.

> You need to take care of proper locking.

Yeah.  I wasn't contending that we needed to avoid it to avoid locking, but
that the signal mansync implementation just makes locking extremely
difficult to do.  Really, the only way to do safe locking taking signals
into account involves setting the signal mask, which gets messy and is also
expensive under many UNIXes.  It's bad enough that mansync takes over
SIGALRM.

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

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.

> On asynchronous targets, you will be in serious trouble, if
> no proper locking is done.

Well, we should have proper locking no matter what.  And we're in trouble
anyway.  LibGGI is currently very un-thread-safe.

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

Right.  As far as I know, ggiFlush() is in fact synchronous for all the
targets I know about, however, or at least if it isn't it's not going to be
affected by blocking calls.  Give me some examples to the contrary.

> > default. ASYNC is better. Yes Xlib works by ASYNC. Also being a X windows
> > programmer there is a specail call that can force Xlib into SYNC mode.
> > This is only to debug programs. Its nice to see when a error occurs in
> > your program. In ASYNC mode you can't tell when the error occured.
> 
> 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.

Oh, yeah.  I really hadn't considered that.  Although that wasn't really
what I was promoting anyway, even though I think I did suggest something
like that earlier on.

> GGI sync modes flushes at reasonable intervals, to keep the user updated.
> 
> The best example I think is say a raytracer or some other thing that
> calculates a picture. 
> 
> If we had no sync mode, we would have three options for flushing:
> 
> 1. At the end of the frame. No wasted cycles, but the user doesn't get 
> updated.
> 2. at regular intervals (pixel-wise), i.e. every line or every pixel.
> This wastes cycles, if the calculation runs fairly quick compared to
> the calculation
> 3. Check at every pixel, if a certain amount of time has passed since the
> last flush and flush in that case. That is rather optimal, but a bit
> complicated.

> SYNC mode is effectively 3. Without any complication. 

Right.  i.e. call ggiFlush() at regular intervals from another thread, which
goes real easily in a small extension library.

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

Eh... not really.  The application programmer needs to select the signal,
not the user via an environment variable.  Although I guess
environmnent variables can be used for intra-application
communictation, the question "why?" comes to mind... 

Different software may require the use of different signals.  I'd just as
soon the additional complexity required to the signal mansync implementation
from interfering with the functioning of the application wasn't pushed on
the user as well as the programmer.  The environment variable may be
appropriate for determining the flush intervals, though.

> > I just hate suser their. Could we put suser in fbcon-kgi.c and pass 
> 
> I'd just add some "checkpriv()" call to the KGI API which will get mapped to
> system-specific priviledge checking mechanism.
> 
> DOS would return 1, Linux probably suser(), someone else might want to
> return (user==graphicsmanager) ...

Yeah, that seems appropriate.

-=MenTaLguY=-