Hi Costas,
On 3/7/23 01:52, Costas Argyris via Gcc-patches wrote:
This is a proposal for addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
by integrating the UTF-8 manifest file into gcc's build process for the
64-bit mingw host.
Is there a reason to make it specific to x86_64?
Hi Costas,
On 3/7/23 15:00, Costas Argyris wrote:
Hi Jacek,
"Is there a reason to make it specific to x86_64? It seems to me that
all mingw hosts could use it."
Are you referring to the 32-bit host? My concern here is that this
functionality (embedding the UTF-8
manifest file into the ex
The problem about this approach is that, semaphores are valuable kernel objects, and the maximum
number of HANDLEs that a process can open concurrently has a limit (like FDs on Linux), while 'many
critical sections are used only occasionally (or never at all), meaning the auto-reset event often
On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
/How does this compare with Eric B's proposal at />>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html
? />>//>>/My proposal was to reimplement (and extend) the native thread model />>/(win32) />>/instead
of adding a new one
On 10/21/22 14:29, LIU Hao wrote:
在 2022/10/21 20:13, Jacek Caban 写道:
This is not true for past 15 years, CRITICAL_SECTIONS use something
like RtlWaitOnAddress (an equivalent of futexes) since Vista, see
Wine implementation for details:
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/
On 10/24/22 05:40, LIU Hao via Gcc-patches wrote:
在 2022/10/21 20:34, i.nix...@autistici.org 写道:
got it...
anyway it seems logical to me the way I proposed :)
Below is a message forwarded from mingw-w64-public, elaborating the
necessity of a new thread model.
As there are objections from
