From: Steve Cheng <elmert@ipoline.com>
  To  : MenTaLguY <mentalg@geocities.com>
  Date: Sat, 29 Aug 1998 12:59:48 -0400 (EDT)

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

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

[nice idea snipped.]

> > 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).
> Maybe not a deadlock, but possibly a race condition -- in any case, what
> problems arose, if any, would be highly implementation-dependent.

Ah that sucks

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

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

> ints are not really safe. not for signals, not for anything. 

It *seems* to work now.

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.

--
Steve Cheng

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