From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: "Miguel Ángel Arruga Vivas" <rosen644835@gmail.com>,
"Michele Locati" <michele@locati.it>
Subject: buy into mingw winpthreads?
Date: Sat, 18 May 2019 15:07:35 +0200 [thread overview]
Message-ID: <1724929.9kHdRrDAm7@omega> (raw)
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/
next reply other threads:[~2019-05-18 13:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-18 13:07 Bruno Haible [this message]
2019-05-18 20:23 ` buy into mingw winpthreads? LRN
2019-05-18 22:42 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1724929.9kHdRrDAm7@omega \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=michele@locati.it \
--cc=rosen644835@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).