No access to uv_get_osfhandle from N-API

[primeare]

The problem is that file descriptors returned by Node.js cannot be used to convert them into Windows file handlers (for instance using _get_osfhandle from Windows API). That problem was disscussed before in issues: node#6369 and libuv#1323. Libuv team has made uv__get_osfhandle function public to use inside of native addons, and I think this function solves the problem, but there is no port of this function into N-API.

[bnoordhuis]

It would be better to obviate the need for uv_get_osfhandle() because it's really just a hack to get around the fact that add-ons link in their own copy of the CRT (the /MT link flag.)

Fix that by linking against node's copy and things like _get_osfhandle() and _open_osfhandle() magically start working.

[primeare]

Thanks, @bnoordhuis! I was wondering how to make a fix that you said. Can you help me with this? What I need to add to my code or what I need to configure? I saw, that in libuv function uv_get_osfhandle() they simply turns off CRT assertion.

[bnoordhuis]

Add-ons use node's common.gypi during the build; node-gyp downloads it. Because node builds with /MT, add-ons do too.

I haven't fully thought out how yet but add-ons should stop using /MT (could probably suppress it in node-gyp's addon.gypi) and start linking against the CRT from node.exe.

I don't know if node.exe currently re-exports symbols from msvcrt.lib. If the answer is "no, it doesn't", then that's the first order of business.

[primeare]

Hmm @bnoordhuis, I discovered something interesting: I have tried to use uv_get_osfhandle function in my code and it works! I don't know how, but I think that's because somewhere in dependencies there is an include with that function. Anyway, what can we do to disable /MT flag in addons and start linking against the CRT from node?

[bnoordhuis]

what can we do to disable /MT flag in addons and start linking against the CRT from node?

Experiment! :-) Clone node and node-gyp and see if you can make it work locally. Once you have an idea of what's involved, we can discuss next steps.

node-gyp accepts a --nodedir <path> argument. Point it to your node checkout to make it pick up your changes to common.gypi.

[simonbuchan]

As mentioned by @primeare it works fine to #include <uv.h>, but AFAIK that's not really considered part of N-API, and thus doesn't have ABI guarantees. But the existence of napi_get_uv_event_loop() is then a bit confusing - I'm guessing it's there as an escape hatch. Does that all sound right?

Personally I'm not sure if I'd like to see N-API be a general ECMAScript engine native API with node-specific escape hatches or to be quite node-concept specific. For example, should it expose crypto in some future version?

In any case, I think exposing napi_{get,open}_osfhandle() is probably better than trying to mess with link flags, as the latter adds a subtle dependency on the library ABI as part of the ABI guarantee N-API gives. If I understand correctly, for example, this means a debug build of node couldn't load addons without a rebuild, since it (I assume) uses /MTd, and using /MD means you're adding an external runtime dependency, where there wasn't one before (with VC++ moving to a stable libc/++ ABI, that's way less of an issue, but hey, still not great)

[mhdawson]

napi_get_uv_event_loop is odd, we might have made a mistake on that one but I can't remember the history on that one.

[mhdawson]

I'm going to close this as there has been no follow up from the op for quite some time. Closing, please let us know if that is not the right thing to do.