Upstream into MinGW?

Question

Upstream into MinGW?

Opened this issue 5 years ago · 11 comments

Is there any effort being made to upstream this into MinGW?

Answer 1 · 2019-09-07T21:21:49.000Z

I am not currently aware of any such effort. We have reached a point where such an effort would be reasonable, but such an effort was not yet sparked.

That said, there are a few features specified by the C++ standard that are not yet implemented by this library:

std::packaged_task lacks any implementation in these headers.
std::notify_all_at_thread_exit is not implemented. To cut a long story short, performing an action after all thread_local variables are destroyed is difficult to guarantee; for the related functions set_value_at_thread_exit and set_exception_at_thread_exit in std::promise, we are able to create another thread as a listener to perform code after the original thread finishes. For std::notify_all_at_thread_exit, however, this would require transferring control of a mutex from one thread to another... without unlocking it.

There are also various desirable features that have not yet been implemented, but which would be good to add for MinGW

C++20 thread support library features.
Ensuring function signatures compatible with all known C++ versions.
The entire C11 thread-support header (<threads.h>) has been ignored, as this project has focused on C++ instead.

Answer 2 · 2019-09-08T12:34:31.000Z

@nmcclatchey The lack of mutex and condition-variable support in the win32 thread model in mingw has been an on-going issue for users trying to build DXVK in Gentoo and other distributions. In Gentoo, at least, it is possible after jumping through some hoops to build a posix thread model toolchain, but the details of how that works does not play nicely with system updates. If I recall correctly, our package manager treats builds as being idempotent and the way that the posix thread model toolchain is built is bootstrapped, which is not idempotent friendly.

I have a WIP DXVK branch that uses your code to make the builds work, but the DXVK author does not like the size of the headers and would rather that we upstream this into mingw:

https://github.com/ryao/dxvk/tree/win32-thread-model-support

I am not sure how many cycles that I have to dedicate to this, but would it be alright if I tried kicking off the upstream process by getting a branch for a possible mingw pull request together? I expect that MinGW would require signed off from mega nz (as do most well established projects), so there would be no point in starting that unless you are willing to provide signed off. I would rather find out now than after I found some time to put into preparing a branch to use in a hypothetical pull request.

Answer 3 · 2019-09-09T05:28:14.000Z

@ryao Though I will whole-heartedly support you in upstreaming this, I am not affiliated with Mega NZ (I just contribute to this library). I believe that the correct person with whom to discuss the necessary dual-licensing is @alxvasilev .

Please keep me in the loop regarding the MinGW-w64 pull request. There are several aspects of this library that can be streamlined if a minimal MinGW version can be assumed (including using __invoke, using __is_invocable, reducing code duplication, etc.).

Answer 4 · 2019-09-15T20:56:26.000Z

In fact there was an idea, long time ago, to include this library in mingw-w64, which was discussed here https://sourceforge.net/p/mingw-w64/mailman/message/33144181/
To facilitate the inclusion I changed the license, however no further actions were taken by the community. Some time later someone raised the question again here
https://sourceforge.net/p/mingw-w64/mailman/message/33592988/
and one of the answers was that no one had offered a pull request to include it. In case you are willing to do that, I will support it.
There is one more thing though - I am not completely sure if this project takes the optimal approach to implementing full thread support in both C++11 and C11, and with minimal effort. Maybe implementing a native win32 port of the gthreads API (on top of which all thread support in gcc is implemented) would be a more rational solution (albeit somewhat less efficient due to the additional layer).

Answer 5 · 2019-09-16T16:49:05.000Z

@alxvasilev The current approach used here is vastly preferable to the status quo, which is causing problems on Gentoo when cross compiling Windows software like DXVK and D9VK. Thanks for being open to moving this forward. I will see what I can do in my spare time and get back to you in a few weeks.

Answer 6 · 2019-09-25T15:44:58.000Z

Great! Thanks in advance for your effort!

Answer 7 · 2021-03-12T10:28:20.000Z

Have there been any news on this?

Answer 8 · 2021-03-25T16:12:09.000Z

No, unfortunately.

Answer 9 · 2021-12-19T06:57:54.000Z

Can the venerable owner of this repository elaborate the following sentence:

It seems that recent versions of MinGW-w64 include a Win32 port of pthreads, and have the std::thread, std::mutex, etc. classes implemented and working based on that compatibility layer.

Is it going upstream?

Answer 10 · 2022-04-06T06:05:01.000Z

There are two versions of mingw-w64, based on threading support - one of them uses a pthread emulation layer for access to all threading functionality of Windows. Namely that version has std::thread, std::mutex, etc classes. The drawback is low performance.

Answer 11 · 2022-07-06T17:06:12.000Z

Do you have any interest in https://github.com/lhmouse/mcfgthread/ which implements a new thread model that is both efficient and standard-compliant. Prebuilt binaries are available at https://gcc-mcf.lhmouse.com/.