Re: multithread modules

[Yoann Vandoorselaere]

Le jeudi 06 mars 2008 à 14:10 +0100, Bruno Haible a écrit :
> Simon Josefsson wrote:
> > Hm.  lock.m4 contains:
> > 
> >     # For using <pthread.h>:
> >     case "$host_os" in
> >       osf*)
> >         # On OSF/1, the compiler needs the flag -D_REENTRANT so that it
> >         # groks <pthread.h>. cc also understands the flag -pthread, but
> >         # we don't use it because 1. gcc-2.95 doesn't understand -pthread,
> >         # 2. putting a flag into CPPFLAGS that has an effect on the linker
> >         # causes the AC_TRY_LINK test below to succeed unexpectedly,
> >         # leading to wrong values of LIBTHREAD and LTLIBTHREAD.
> >         CPPFLAGS="$CPPFLAGS -D_REENTRANT"
> >         ;;
> >     esac
> > 
> > This seems to imply that if I don't use pthread.h, I won't find
> > -D_REENTRANT useful
> 
> No, that's not implied by the above statement. The above statement only
> says that
> 
>   #undef _REENTRANT
>   #include <pthread.h>
> 
> will lead to an error on OSF/1.
> 
> > except for possibly the next statement:
> > 
> >     # Some systems optimize for single-threaded programs by default, and
> >     # need special flags to disable these optimizations. For example, the
> >     # definition of 'errno' in <errno.h>.
> >     case "$host_os" in
> >       aix* | freebsd*) CPPFLAGS="$CPPFLAGS -D_THREAD_SAFE" ;;
> >       solaris*) CPPFLAGS="$CPPFLAGS -D_REENTRANT" ;;
> >     esac
> > 
> > Do you know any operating system manuals that document this?  I'm trying
> > to understand precisely when I need to use any of these flags.
> > 
> > Generally, if some systems need -D_REENTRANT to get a usable errno,
> 
> The above list of platforms was indeed compiled by looking for a multithread-
> aware errno.
> 
> > wouldn't that be something we could write a gnulib module for?
> 
> I can see three levels of multithreading support that you might ask for:
>   1) just turn on multithreading, and 'errno',
>   2) also use locks,
>   3) also use primitives that create and control threads.
> 
> #2 is what the 'lock' module currently implements.
> 
> #1 is not a practical use-case for me, since at some point one needs global
> variables and therefore locks. But if it is useful for you, we can split off
> part of the 'lock' module into a module that does just #1.

Implementing #1 sound like a good idea for any library using GnuLib
without directly depending on multithreading. 

The acx_pthread autoconf macro
(http://autoconf-archive.cryp.to/acx_pthread.html) does this.

Reading the documentation, I can see:

"Also sets PTHREAD_CC to any special C compiler that is needed for
multi-threaded programs (defaults to the value of CC otherwise). (This
is necessary on AIX to use the special cc_r compiler alias.) "

Shouldn't the GnuLib lock module implement this feature?

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com