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

Re: SYNC mode should go

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

> > > > This does not save you the locking for all targets.
> > All of LibGGI is supposed to be thread-safe.  This is no different from
> > calling LibGGI functions in separate threads together.
> > Flushing on signals is a losing position, if someone wants to do it, let
> > him/her implement the signal mask stuff himself/herself.
> 
> What is the big difference ?
> If we do proper locking and abstract it, we should be able to make a lock
> mechanism for threads as well as one for signals - or ?

The _only_ way to safely lock with asynchronously delivered signals is to
manipulate the signal mask, which is a relatively expensive operation under
most UNIXes.  The reason for this is that signals can preempt, but control
cannot return to the main code until the signal hander exits outright.  As a
result, unless you mask out all signals while there is at least one lock
locked, you are in severe danger of deadlocks.  (even
pthread_mutex_trylock() is not async-signal-safe, as it can deadlock on the
spinlock).

Masking out all signals while at least one lock may be is locked is
problematic, in that you could potentially nearly always have at least one
lock locked, so the signals would never get delivered.

POSIX does not guarantee the async-signal-saftey of the thread-related calls
for very good reasons.

For the last time, forget about async-signal-saftey.

> >   When the drawing command returns, it is already or will be
> >   executed very shortly. So the visible effect is that everything is
> >   drawn immediately.  (It is not guaranteed in the strict sense that it
> >   is already drawn when the function call returns, but almost.)
> > 
> > Flushing 20 times per sec from a separate thread,process,signals does not
> > guarantee this, nor should we (at least in theory) fool the application that
> > it is.  In other words, don't try to emulate it if it is not possible. 
> 
> Why doesn't it ? It ensures the screen gets updated at about max 50ms
> after the command complets - what's wrong with that ?

Yes.  It does fit the definition.

> > (Note that X-lib target's SYNC mode is still alright, because in fact it
> > does synchronize after each operation.)
> 
> I think we need to set some definitions straight :
> 
> SYNC mode (as in LibGGI) is there to give the application the "feel" like 
> it would be running on DOS or something where you have direct HW access.
> The idea is, that applications ported from there do not need a lot of
> effort. Note that you often have to port foreign code. Ask Wouter about
> Descent ...
> 
> SYNC mode is there to avoid waiting for keystrokes while the menu is not yet
> drawn etc.
> 
> What I call SYNC mode here is fundamentally different from what X calls
> SYNC.
> 
> 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.

That can be fixed in the X target, although it'd be difficult to do without
requiring thread support...

I find myself starting to wonder if we shouldn't just require pthreads and
be done with it, since that'd let us fix an awful lot of things, including
ditching the broken signal mansync implementation...

-=MenTaLguY=-