Index:
[thread]
[date]
[subject]
[author]
From: Steve Cheng <elmert@ipoline.com>
To : GGI ML <ggi-develop@eskimo.com>
Date: Sun, 30 Aug 1998 23:54:08 -0400 (EDT)
Re: LibGGI Thread-safety (was Re: Some things that seem to be missing)
On Sat, 29 Aug 1998, MenTaLguY wrote:
> > 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.
Ah, I was thinking of LinuxThreads' PTHREAD_MUTEX_RECURSIVE_NP.
> 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.
Yes, please do so. (I'm busy with DocBook stuff right now.)
> > 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.
Ok. But just require multi-threading support enabled if LibGGI wants to use
threads for itself.
> 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)
Don't see a problem here. README.LinuxThreads says:
# WARNING:
#
# Many existing libraries are not compatible with LinuxThreads,
# either because they are not inherently thread-safe, or because they
# have not been compiled with the -D_REENTRANT. For more info, see the
# FAQ.html file in this directory.
#
# A prime example of the latter is Xlib. If you link it with
# LinuxThreads, you'll probably get an "unknown 0 error" very
# early. This is just a consequence of the Xlib binaries using the
# global variable "errno" to fetch error codes, while LinuxThreads and
# the C library use the per-thread "errno" location.
> > 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.
Thought about it again: I think we don't need to depend on
pthread_mutex_trylock() being async-signal safe anymore, since it would be
better if thread-safe LibGGI used *only* pthread for mansync, and
non-thread-safe LibGGI used signals only. It's the only reasonable and
clean way.
--
Steve Cheng
email: steve@ggi-project.org
www: <http://shell.ipoline.com/~elmert/>
Index:
[thread]
[date]
[subject]
[author]