Re: threadlib vs. pthread modules

[Paul Eggert]

On 09/22/10 08:18, Bruno Haible wrote:

> Would you (in coreutils, sort) be willing to use such an API that is
> slightly different from POSIX, but much closer to POSIX than
> 'lock', 'tls', 'cond', 'thread', 'yield' are now?

Yes, that sounds like a better option, thanks!  Two further thoughts.


First, for coreutils there's no need to implement the POSIX API for
recursive locks and for pthread_key_t, since coreutils doesn't need
those features.  That is, instead of supplying a superset of a subset
of POSIX pthreads, it'd be fine to support just a subset of POSIX
pthreads.

If other applications need features where the POSIX API is hard to
support portably, we can worry about those features later (perhaps
never :-).  I'd rather that coreutils didn't have to deal with any
hassles in supporting pthreads features it doesn't need.  Perhaps
harder-to-support API features could be put into new modules, that the
pthread module would be a prerequisite for.

If it helps to simplify the work, here are the only pthread.h
features that coreutils needs:

  pthread_t, pthread_cond_t, pthread_mutex_t, pthread_spinlock_t
  pthread_create/join/destroy
  pthread_spin_init/lock/unlock/destroy
  pthread_cond_init/signal/wait/destroy
  pthread_mutex_init/lock/unlock/destroy

All spinlocks are created with PTHREAD_PROCESS_PRIVATE; all other
objects are created with default attributes.  Currently, on hosts
that have other pthreads features but not spinlocks, spinlocks
are emulated with mutexes.


Second, suppose we want to support coreutils' preference, of using
POSIX threads in sort, while not making the other gnulib functions be
thread-safe, because we know that 'sort' (and other coreutils apps, of
course) never invoke these gnulib functions from competing threads.  I
assume gl_THREADLIB_DEFAULT_NO wouldn't be enough to support this
need, because it would shut off all threading, even in 'sort'.  So
it'd be nice to have a way to support this need, too.