Index:
[thread]
[date]
[subject]
[author]
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/>
Index:
[thread]
[date]
[subject]
[author]