RFR: 8299343: Windows: Invalid thread_native_entry declaration
Julian Waters
jwaters at openjdk.org
Mon Dec 26 16:25:47 UTC 2022
On Mon, 26 Dec 2022 07:57:38 GMT, David Holmes <dholmes at openjdk.org> wrote:
> Why do we want/need this to be a C++ static member function? The thread entry points are always plain C functions.
8299343 mentions how the Windows declaration is shaky due to the friend specification causing it to be initially declared extern implicitly, while it is later marked static at the definition, which makes it very likely to fail if flags such as `-permissive-` are passed, which is going to become the default compilation mode for Visual C++ in the future. Other solutions like leaving the thread native entry definitions extern seem to be undesirable, if memory serves me right. Maybe we could change all the thread native entry declarations to be static members if they should be uniform? All are statically scoped at the moment meaning changing them to members doesn't seem to have much of an effect on them, at least from my perspective
-------------
PR: https://git.openjdk.org/jdk/pull/11787
More information about the hotspot-runtime-dev
mailing list