buy into mingw winpthreads?

[Bruno Haible]

Hi,

What should be the default threading API used by the module 'threadlib'
(and thus also 'lock', 'rwlock', 'cond', etc.) on mingw. There are two choices:

--enable-threads=windows
  does not need non-Microsoft DLLs.

--enable-threads=posix
  links against winpthreads.dll.
  (Whereas Ross Johnson's pthreads-win32 [1] is apparently no longer maintained 
for
  7 years, therefore no viable option.)
  
Arguments I can see in favour of --enable-threads=windows:

  * The gnulib threads code (lib/glthread/) for Windows is much smaller than the
    one in mingw's winpthreads, thus contains likely fewer bugs.

  * The gnulib threads code is portable across architectures; no 
assembly-language
    code.

  * It makes me nervous to see that, 5 years after winpthreads was declared no
    longer experimental (in 2013), we still see fixes of race conditions and 
dirty hacks:
      2019-04-26  winpthreads/cond.c: Remove waits for `sema_b` from wait 
functions.
      2019-04-26  winpthreads/cond.c: Only update `waiters_count_` with 
`waiters_count_lock_` locked.
      2017-03-10  winpthreads/src/thread.c: Force aligning ESP on 16-byte 
boundaries on x86.
      2016-11-24  winpthreads mem leak fixed

  * One less DLL dependency.

Arguments I can see in favour of --enable-threads=posix:

  * The mingw platform is moving away from a "minimal" layer on top of
    Windows towards an ISO C + POSIX layer. There is no point in working
    against this evolution.

Opinions?

Bruno

[1] https://sourceware.org/pthreads-win32/