[Top][All Lists]

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

Re: cnd_timedout returns immediately when built with MinGW

From: Tim Rühsen
Subject: Re: cnd_timedout returns immediately when built with MinGW
Date: Sat, 6 Aug 2022 20:15:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.0

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

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

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 <threads.h> 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


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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