From: MenTaLguY <mentalg@geocities.com>
  To  : Steve Cheng <elmert@ipoline.com>
  Date: Sat, 29 Aug 1998 18:43:43 -0500 (EST)

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

On Sat, 29 Aug 1998, Steve Cheng wrote:

> On Sat, 29 Aug 1998, MenTaLguY wrote:
> 
> > Well, not just for mansync.  If locks were made recursive in some fashion,
> 
> Recursive locks are not portable... :-(

Sure they are.  I've implemented them in a portable fashion before, using a
structure with a mutex, an integer counter, and a condition variable.  And
we can always have an #ifdef in there to use Linuxthreads's faster
non-portable implementation of them if it is availible. 

Once I get the glibc issues sorted out on my system so I can compile things
again (header files are way screwed right now), I'll code the recursive lock
thing. 

> > If POSIX threads are supported by the target system, it should use mutexes
> > for locking instead of ints, even if explicit multi-threading support is not
> 
> But THAT IS the point of multi-threading support -- libGGI doesn't start its
> own threads except mansync -- to make LibGGI functions threadsafe/reentrant. 

*except mansync for now* ... but specific targets/extensions/whatever may
benefit from using their own threads in the future.  you never know.

> > enabled for libGGI.  GNU autoconf or some other similar detection setup
> > would be extremely useful for that.
> 
> The Makefile gurus: how about we make multi-threading default if POSIX
> threads are detected?  (Right now there's some big warning about enabling
> multi-threading support but I don't get why it's there.)  LinuxThreads seems
> to bite libc5 last time I tried it though.

Xlib dies for unknown reason if you try enabling thread support, even though
they are not used.  Was that ever fixed? (I don't seem to recall that we
ever figured out why it was even happening -- it was even a problem with the
'thread-safe' x libraries)

> > ints are not really safe. not for signals, not for anything. 
> 
> It *seems* to work now.

Unless the test-and-set operation is truly a single, atomic, operation,
there is a race condition.  The window is small (one or two instructions,
probably), so it's unlikely to be triggered ... but it can be.  We have
spinlocks for just that reason. 

> But that's what you get for not using multi-threading support, or something
> as evil as flushing on signals.  I'd say, if multi-threading is enabled,
> just make the pthread.c version of mansync the default (therefore no
> async-signal issues).  Of course, even better if you don't use mansync at
> ALL.

Well, yeah.  mansync is an ugly hack at best.

-=MenTaLguY=-