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.
