RFR: 8299343: Windows: Invalid thread_native_entry declaration

[Kim Barrett]

On Tue, 27 Dec 2022 02:19:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > And referring to the definitions for the other platforms as "plain C functions" is something of a misnomer;
> 
> Perhaps, but the thread creation functions (_beginthreadex and pthread_create) are themselves plain C API's not C++. It seems to me that the fact a static C++ member function is equivalent to a static C++ non-member function here and both work, is itself the fortuitous accident. If there were indeed an issue with C++ versus C calling convention then we would need to switch to the C convention.
> 
> I agree it is nicer from an encapsulation pov that these are member functions, but when we are using thread creation routines that are extra-lingua we have to expect to make some concessions.

A non-member C++ function (whether file-scoped or having external linkage) is
no more C-like than a static member function. The differences are in naming
and scoping rules, which are C++ properties. They must be ABI-compatible with
each other, because C++ doesn't make a distinction between them for purposes
of passing them around as function pointers.

I think a C++ function is not required to be ABI-compatible with a C function,
but implementations don't make them unnecessarily different because that would
be painful for interoperability. So the compatibility is not a fortuitous
accident; it's intentional.

MSVC has multiple function call ABIs, on which the function definition and
call site must agree; hence the use of the compiler-specific `__stdcall`
qualifier when declaring/defining the function in question.

-------------

PR: https://git.openjdk.org/jdk/pull/11787