Re: [PATCH 01/10] thread-utils: macros to unconditionally compile pthreads API

[Jeff King <peff@peff.net>]

On Sat, Oct 27, 2018 at 09:09:54AM +0200, Nguyễn Thái Ngọc Duy wrote:

> +/*
> + * macros instead of typedefs because pthread definitions may have
> + * been pulled in by some system dependencies even though the user
> + * wants to disable pthread.
> + */
> +#define pthread_t int
> +#define pthread_mutex_t int
> +#define pthread_cond_t int
> +
> +#define pthread_mutex_init(mutex, attr) dummy_pthread_init(mutex)
> +#define pthread_mutex_lock(mutex)
> +#define pthread_mutex_unlock(mutex)
> +#define pthread_mutex_destroy(mutex)

OK, we only need to do the dummy init to shut up the compiler, and the
rest really can just become noops. Makes sense.

> +#define pthread_cond_init(cond, attr) dummy_pthread_init(cond)
> +#define pthread_cond_wait(cond, mutex)
> +#define pthread_cond_signal(cond)
> +#define pthread_cond_broadcast(cond)
> +#define pthread_cond_destroy(cond)

And this is the same.

> +#define pthread_key_create(key, attr) dummy_pthread_init(key)
> +#define pthread_key_delete(key)

We don't need keys because we know we have only one key: the main
thread. Makes sense. But...

> +#define pthread_setspecific(key, data)
> +#define pthread_getspecific(key) NULL

We expect to be able to store a void pointer here and get it back, which
should work even for a single thread. Do we need something like:

  extern void *pthread_specific_data;

  #define pthread_setspecific(key, data) do { \
	pthread_specific_data = data; \
  } while(0)

  void pthread_getspecific(key) pthread_specific_data

> +#define pthread_create(thread, attr, fn, data) \
> +	dummy_pthread_create(thread, attr, fn, data)

I wondered if this should actually run "fn", but I guess there is not
much point. At this point the caller expects the main thread to keep
going, so this is already an error, and reporting ENOSYS is probably the
best thing to do.

-Peff