[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7073: threadlib vs. pthread modules

From: Paul Eggert
Subject: bug#7073: threadlib vs. pthread modules
Date: Wed, 22 Sep 2010 10:48:42 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.0.8

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]