On Thu, 2 Oct 2025, Kirill Makurin wrote:
When I was writing the patch series I ran the tests locally with 32-bit msvcrt.dll, 64-bit UCRT (gcc) and 64-bit MSVC. I did not see pthread_rwlock/rwlock6_t failing. Looking at this test, it seems simple enough to me. Maybe we can reduce chance of spurious failures by removing `-j$(nproc)` from winpthreads' `make check`?
I had a look now - there's a risk that rdt2 starts executing before wrt1 has released the writelock, and then there's probably no guarantee whether wrt2 or rdt2 gets the lock first? If the sleep between starting wrt2 and rdt2 is increased from 1000 to 1500, there should be less risk for that.
Running the tests without -j can of course reduce the risk of such issues, but ideally the testcases themselves should be less brittle so we don't need to do that.
Is there anything left to fix or change? If we're good with this patch series, could you just replace my 5th patch with yours and remove "continue-on-error: true" after applying patch 12? (maybe as well remove `-j$(nproc)`)
I can do those changes, yeah. I'm still waiting for review of "Use non-SEH setjmp/longjmp for pthread_cancel arm/aarch64", "Skip the pthread_exit/exit1.c testcase on ARM" and "Reduce the number of threads created in a test on 32 bit" patches that I sent yesterday, though. Then I'd re-read your updated patchset (I haven't read the second round closely yet, I've only applied it and tested it).
With those things in place, and if a re-read of the patchset doesn't find anything else problematic, we could indeed apply it.
As a separate follow-up wish: As you and others have spent effort in making winpthreads build successfully with MSVC, it would be nice to have some test coverage, or at least build coverage of that as well. Can you look into setting such a configuration up in our github actions? It could be a separate job, not tied to the rest of them. See e.g. https://github.com/mstorsjo/FFmpeg/blob/28e80dc0ffaa5fb1b2f57fb932037fe2c20799fc/.github/workflows/aarch64.yml#L216-L246 for an example of how to make MSVC available (through the ilammy/msvc-dev-cmd step), then msys2/setup-msys2 with "path-type: inherit" to get msys2, while keeping the external global PATH intact, then a job with "shell: msys2 {0}" for an environment where you can run the autotools build.
I presume it is possible to build the library through autotools with MSVC somehow? Having such a test setup in place also serves as a documentation of one working configuration of achieving that.
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
