Discussion:
How to circumvent MinGW's broken pthread_cond_broadcast()
(too old to reply)
Tim Rühsen
2017-09-30 17:17:51 UTC
Permalink
Raw Message
Hi,

pthread_cond_broadcast() on MinGW is broken in such that it sometimes doesn't
wake up all threads. This leads currently to easily reproducible 'hangs' in
the MinGW64 test suite of Wget2.

The good thing: It made me switch to glthreads today, which immediately worked
on my Debian box with a native build. Thanks for glthreads !

But the hangs still occur for my MinGW64 build - looking at it... yes, it uses
pthreads. So no surprise here.

My question: How can I force the MinGW build to ignore pthreads and use the
native Win32 API ? (I am using gnulib's bootstrap script + ./configure, make,
make check.)

With Best Regards, Tim
Bruno Haible
2017-09-30 18:08:46 UTC
Permalink
Raw Message
Post by Tim Rühsen
My question: How can I force the MinGW build to ignore pthreads and use the
native Win32 API ? (I am using gnulib's bootstrap script + ./configure, make,
make check.)
Did you try the --enable-threads=windows option, provided by the 'threadlib'
module?

Bruno
Tim Rühsen
2017-09-30 21:18:20 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Tim Rühsen
My question: How can I force the MinGW build to ignore pthreads and use the
native Win32 API ? (I am using gnulib's bootstrap script + ./configure,
make, make check.)
Did you try the --enable-threads=windows option, provided by the 'threadlib'
module?
Didn't know about that, very handy.

Sadly, the build fails with:

In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
from fatal-signal.c:26:
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^
Makefile:1905: recipe for target 'fatal-signal.lo' failed
make[3]: *** [fatal-signal.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
from sig-handler.h:21,
from sig-handler.c:3:
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^


Not sure why pthread_sigmask appears here. I removed pthread module from the
modules list, but it doesn't make a difference.

Line 593/594 from lib/signal.h:
_GL_FUNCDECL_SYS (pthread_sigmask, int,
(int how, const sigset_t *new_mask, sigset_t *old_mask));

gnulib is pretty up-to-date here (at 07a187be7).

Any idea ?

Regards, Tim
Tim Rühsen
2017-10-01 19:21:49 UTC
Permalink
Raw Message
Post by Tim Rühsen
Post by Bruno Haible
Post by Tim Rühsen
My question: How can I force the MinGW build to ignore pthreads and use the
native Win32 API ? (I am using gnulib's bootstrap script + ./configure,
make, make check.)
Did you try the --enable-threads=windows option, provided by the
'threadlib' module?
Didn't know about that, very handy.
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^
Makefile:1905: recipe for target 'fatal-signal.lo' failed
make[3]: *** [fatal-signal.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /usr/share/mingw-w64/include/signal.h:10:0,
from ./signal.h:52,
from sig-handler.h:21,
./signal.h:593:1: error: expected identifier or '(' before numeric constant
_GL_FUNCDECL_SYS (pthread_sigmask, int,
^
FYI, it builds with this sequence
PREFIX=x86_64-w64-mingw32
export CC=$PREFIX-gcc-win32
export CXX=$PREFIX-g++-win32
export CPP=$PREFIX-cpp-win32
export RANLIB=$PREFIX-ranlib
./configure --build=x86_64-pc-linux-gnu --host=$PREFIX

I have not found any docs about this, it was just out of intuition (a lucky
punch).

The cond_broadcast hang doesn't occur any more - interestingly Win32 threads
seem to have a different switching behavior than pthreads. Now I see a second
hang which likely comes from a flaw in my code. I'll track this down in the
next days.

Regards, Tim
Bruno Haible
2017-10-01 20:10:17 UTC
Permalink
Raw Message
Post by Tim Rühsen
FYI, it builds with this sequence
PREFIX=x86_64-w64-mingw32
export CC=$PREFIX-gcc-win32
export CXX=$PREFIX-g++-win32
export CPP=$PREFIX-cpp-win32
export RANLIB=$PREFIX-ranlib
./configure --build=x86_64-pc-linux-gnu --host=$PREFIX
I have not found any docs about this
My preferred recipe for building GNU packages for mingw is here:
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob_plain;f=README.windows

The major difference between my recipe and yours is that you are building on
Linux. How do you execute the built binaries? If with WINE, how do you make
sure you are not observing a WINE bug?

Bruno
Tim Rühsen
2017-10-03 11:02:21 UTC
Permalink
Raw Message
Post by Bruno Haible
Post by Tim Rühsen
FYI, it builds with this sequence
PREFIX=x86_64-w64-mingw32
export CC=$PREFIX-gcc-win32
export CXX=$PREFIX-g++-win32
export CPP=$PREFIX-cpp-win32
export RANLIB=$PREFIX-ranlib
./configure --build=x86_64-pc-linux-gnu --host=$PREFIX
I have not found any docs about this
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob_plain;f=README.wind
ows
The major difference between my recipe and yours is that you are building on
Linux. How do you execute the built binaries? If with WINE, how do you make
sure you are not observing a WINE bug?
That's a good point. I am not sure.
So I now installed CygWin in a Win10 VM - and at least there the hangs are
gone there. But I am also not sure, if CygWin uses the underlying Windows API
or not. Have to make some more experiments.

@Gisle Maybe you can test branch 'tmp-pthread-abstraction' of Wget2 on Windows
? To check if the test suite in tests/ (sometimes) hangs or not.

Regards, Tim

Loading...