From: MenTaLguY <mentalg@geocities.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 20:28:44 -0500 (EST)

Re: Some things that seem to be missing

On Wed, 26 Aug 1998, Steve Cheng wrote:

> On Wed, 26 Aug 1998, Olivier Galibert wrote:
> 
> > I'm reading  the new documentation   and  some useful  functionalities
> > seems to be missing:
> 
> > - creating an "related" visual.  This means creating a visual in a new
> >   display but on  the same graphic device  that a given visual.  Under
> >   X,  it  would open a new  window,  under KGI  it  would create a new
> >   virtual terminal, etc...  One on the targets is to be able to have a
> >   GUI application (under XGGI/Berlin/whatever) that opens a fullscreen
> >   visual in  a  new  mode.  Useful  for  games,  slide   shows, public
> >   interactive systems with touch-screens...
> 
> Simply open the same "display string" again.

If some (non-libggi) library function got the visual from someplace outside,
it may not have a way of knowing what the original display string was.
Additionally, for some strange targets (i.e. terminfo), using the same
display string twice may not have the desired results.  A generic "create a
new visual from this visual" function is sort of needed.  Maybe the "clone
visual" function with a flag or something?

> > - the library  is not thread safe.   This is bad  bad bad bad  bad bad
> >   bad.   This is going back  5-10 years in  time.  It makes code using
> >   active threaded components a tremendous PITA to handle.  It probably
> >   makes gwt next to useless for anything but X.   Oh, and did I say it
> >   is bad?
> 
> Yes, I agree it's a sticky problem.
> Here's what I've been thinking:
> 
> In the targets, driver libraries, etc., do _ggiLock() and _ggiUnlock().
> 
> We don't do it in stubs because e.g. in ggiEventPoll() you might want to
> release the lock for periods of time.  It might also depend on the target:
> e.g. Xlib must lock, but simultaneous drawing on framebuffer should be ok.
> 

> ggiFlush should do a _ggiTryLock(), since that is the current behaviour
> (albeit X locks on ints!), but the real problem is that pthread_mutex_t
> isn't async signal safe, so if we do a _ggiLock() from mansync, we get
> a deadlock.

well... one possible way to do this is make a special provision for
ggiFlush() in _ggiUnlock() -- if the mutex is locked, ggiFlush() would just
set a "need flush" semaphore someplace, which would be checked by
_ggiUnlock(), and if the semaphore was set, _ggiUnlock() would call
_ggiFlush() or somesuch version of ggiFlush() that didn't check the
lock/semaphore.  sem_post is, after all, async-signal-safe.

mmm... but I guess pthread_mutex_trylock still isn't async-signal-safe ... I
dunno.

It's a thought, anyway.

-=MenTaLguY=-