From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 21:09:53 -0400 (EDT)

LibGGI Thread-safety (was Re: Some things that seem to be missing)

On Thu, 27 Aug 1998, MenTaLguY wrote:

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

It's too ugly.  We shouldn't hardcode mansync stuff into the _ggiLock stuff.

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

Thought about that too, but I can't see how pthread_mutex_trylock could
cause a deadlock (assuming this is the only problem caused by async-signal
non-safety).

You wrote in another message:

> > - 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, that is INCREDIBLY bad... as few other people seem to care, I'm going
> to have to mess with CVS and start throwing code at thread-saftey myself, I
> guess.

The locking macros (lib/libggi/include/structs.h) has always been there, but
nobody uses them :-(

I'd appreciate any help securing the existing code, but it's just this
mansync dilemma :-(  -- see below.

> Oh, and even the non-threaded version of the library should (must) still be
                   ^^^^^^^^^^^^
The library doesn't start its own thread except the pthread.c of
display/mansync.

> thread-_safe_ (or at least reentrant and maybe async-signal-safe)! Please,
> people... consider the state of the technology!

Is that what people want?  (pseudo-thread-safety without multi-threading
support compiled)

Here's the stuff I wrote:

#define MANSYNC_LOCK(vis) \
        while(MANSYNC_LOCK(vis)++!=0) \
                { MANSYNC_LOCK(vis)--; usleep(1000); }
#define MANSYNC_UNLOCK(vis)     (MANSYNC_LOCK(vis)--)
#define MANSYNC_TRYLOCK(vis)    (MANSYNC_LOCK(vis)++ ? MANSYNC_LOCK(vis)-- : 0)

Yes, locking on ints.  If you don't like that compile with multi-threading
support.  But it's much easier than

#ifdef GGI_X_TARGET
	MANSYNC_LOCK(vis)
#else
	_ggiLock(vis)
#endif

all over the place (well, in any code used by the mansync targets).
Before this I thought to replace the _ggiLock() macros when
display/mansync/mansync.h is included but some stub might want to lock as
well...

--
Steve Cheng

email: steve@ggi-project.org
www: <http://shell.ipoline.com/~elmert/>;