[Top][All Lists]

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

buy into mingw winpthreads?

From: Bruno Haible
Subject: buy into mingw winpthreads?
Date: Sat, 18 May 2019 15:07:35 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; )


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:

  does not need non-Microsoft DLLs.

  links against winpthreads.dll.
  (Whereas Ross Johnson's pthreads-win32 [1] is apparently no longer maintained 
  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 

  * 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 
      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.



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

reply via email to

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