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/>;