cnd_timedout returns immediately when built with MinGW
Hi, I am at switching wget2 multithreading from C99+glthreads to C11 (threads.h). The tests work well on Linux (amd64) (Debian unstable/testing/stable, Fedora 35, Arch, Alpine/muslc) with native builds (gcc or clang). But they completely fail when cross-building with MinGW64 (on Debian bookworm). It looks like cnd_timedwait() always immediately returns with 1, no matter what timeout is specified. The cond is initialized and the mutex is locked. Using cnd_wait() instead of cnd_timedwait() works well, but I'd prefer having using a timeout to catch some corner cases. Is this a known issue ? Regards, Tim OpenPGP_signature Description: OpenPGP digital signature
Re: cnd_timedout returns immediately when built with MinGW
Hi Tim, > I am at switching wget2 multithreading from C99+glthreads to C11 > (threads.h). I hope that you have considered the Gnulib documentation on this topic: https://www.gnu.org/software/gnulib/manual/html_node/Choosing-a-multithreading-API.html > The tests work well on Linux (amd64) (Debian unstable/testing/stable, > Fedora 35, Arch, Alpine/muslc) with native builds (gcc or clang). > > But they completely fail when cross-building with MinGW64 (on Debian > bookworm). And what's the execution environment? Is it Windows or is it wine? wine is not supported; I've had enough work making it work on Windows. Also, are you configuring with --enable-threads=windows? If yes, then it should work (on Windows). If not, then if the winpthreads library is found, it will be used; but since this library is broken, some of the tests will hang, crash, or fail. To avoid using this broken library, add this macro invocation to your configure.ac: gl_AVOID_WINPTHREAD Bruno
Re: cnd_timedout returns immediately when built with MinGW
Hi Bruno, On 05.08.22 20:27, Bruno Haible wrote: Hi Tim, I am at switching wget2 multithreading from C99+glthreads to C11 (threads.h). I hope that you have considered the Gnulib documentation on this topic: https://www.gnu.org/software/gnulib/manual/html_node/Choosing-a-multithreading-API.html Thanks for the pointer. I used the gnulib API in the past and created API wrappers for libwget, so that apps didn't need to use gnulib directly. Since Wget2 is the only app I know that uses libwget, I recently decided to go with ISO C (C11) in the future and drop the libwget thread API completely. The rationale was - gnulib is C11, so the libwget code is - less code = less maintenance - the library code just uses the basic thread, condition and mutex API I read that even the MS C compilers / libraries support ISO C thread nowadays, so ISO C seems OK to me. The tests work well on Linux (amd64) (Debian unstable/testing/stable, Fedora 35, Arch, Alpine/muslc) with native builds (gcc or clang). But they completely fail when cross-building with MinGW64 (on Debian bookworm). And what's the execution environment? Is it Windows or is it wine? wine is not supported; I've had enough work making it work on Windows. Testing with wine, as I don't own a Windows license. Have to carry a USB stick to a friend in order to test on real Windows (trying to avoid that). And yeah, I can fully understand that wine isn't directly supported. It seems to be a can of worms on it's own. Also, are you configuring with --enable-threads=windows? If yes, then it should work (on Windows). If not, then if the winpthreads library is found, it will be used; but since this library is broken, some of the tests will hang, crash, or fail. To avoid using this broken library, add this macro invocation to your configure.ac: gl_AVOID_WINPTHREAD '--enable-threads=windows' does not work with MinGW since 'threads.h' is not available via gnulib then. MinGW also doesn't provide it. It's not 100% clear to me what this option actually does. I'll use gl_AVOID_WINPTHREAD since there are reports from Windows users regarding multi-threading not working as expected (using the gnulib API). Thank you, I appreciate your help & hints ! Regards, Tim Bruno OpenPGP_signature Description: OpenPGP digital signature
Re: cnd_timedout returns immediately when built with MinGW
Tim Rühsen wrote: > I read that even the MS C compilers / libraries support ISO C thread > nowadays, I can't confirm this. If it were true, they would have documentation for it. But a web search for "mtx_lock site:microsoft.com" returns no meaningul results. > Testing with wine, as I don't own a Windows license. > Have to carry a USB stick to a friend in order to test on real Windows > (trying to avoid that). Yes, working like this is tedious. > '--enable-threads=windows' does not work with MinGW since 'threads.h' is > not available via gnulib then. ?? What do you mean? You have imported the 'threads' module, and it provides a file. When I create a testdir for the 'threads' module and build it on mingw, all tests pass, except for a hanging 'test-nanosleep'. Maybe you are lacking a -I directive to the build directory where threads.h has been generated? Bruno
Re: cnd_timedout returns immediately when built with MinGW
On 06.08.22 19:40, Bruno Haible wrote: Tim Rühsen wrote: I read that even the MS C compilers / libraries support ISO C thread nowadays, I can't confirm this. If it were true, they would have documentation for it. But a web search for "mtx_lock site:microsoft.com" returns no meaningul results. You are right. After diving deeper into it, I'd say I was blinded by some overly- enthusiastic comments on social media. Testing with wine, as I don't own a Windows license. Have to carry a USB stick to a friend in order to test on real Windows (trying to avoid that). Yes, working like this is tedious. '--enable-threads=windows' does not work with MinGW since 'threads.h' is not available via gnulib then. ?? What do you mean? You have imported the 'threads' module, and it provides a file. When I create a testdir for the 'threads' module and build it on mingw, all tests pass, except for a hanging 'test-nanosleep'. Maybe you are lacking a -I directive to the build directory where threads.h has been generated? Sorry, when using the shortcut of `autoconf -fi` after adding gl_AVOID_WINPTHREAD, lib/threads.h was gone. A './boostrap' fixed it. I will test '--enable-threads=windows' on real Windows in the next days, but TBH, it feels like the C11 threads experiment failed :-| Maybe there is a (effective) way to rewrite the inter-thread communication avoiding cond_timedwait. Regards, Tim Bruno OpenPGP_signature Description: OpenPGP digital signature
Re: cnd_timedout returns immediately when built with MinGW
Tim Rühsen wrote: > Sorry, when using the shortcut of `autoconf -fi` after adding > gl_AVOID_WINPTHREAD, lib/threads.h was gone. > A './boostrap' fixed it. threads.h, like so many other .h files, is generated by 'make', and erased by 'make distclean'. Bruno
