async_wrap: polyfill

[Qard]

We need a polyfill for the async_wrap API to use in older versions of node/io.js.

It'll need roughly the same monkey-patching that async-listener does, but triggering slightly different things from the calls. Some changes will need to be made to pass around handles.

Concerns:

• Availability of handles on this object of patched functions
• Availability of handles in older node/io.js versions (@trevnorris Comments?)

[trevnorris]

Reaching full parody would be very difficult. Since the init callbacks are called when the C++ class is instantiated, and has no regard for what's happening in JS. Also it's flat impossible for FS because there is no created JS handle.

[Qard]

Yes, I expected some things--handle in particular--would simply not be accessible in past versions.

As for init callbacks, is there a particular case in which you think it'd be an issue to monkey-patch the call itself to represent init, rather than the C++ class instantiation? Other than the slightly different timing, the order of operations should still be the same, shouldn't it? There might be a bit of internal work going on between but, as far as I know, there's nothing that'd be jumping back into JS or triggering other async_wrap events, is there?

[trevnorris]

@Qard Just need to be careful you're patching the correct thing. e.g. you'd have to patch Server#listen() instead of Server(). Because the call to TCPWrap/PipeWrap isn't made until listen() is called b/c it isn't known until that point whether it's a socket or port.

[Qard]

That sounds fine to me. I might actually just go straight for the binding function and patch stuff there. We'll see.

[avanderhoorn]

Did you ever have any luck here, what approach did you end up going with?

[Qard]

Haven't taken the time to do anything with it due to the API not being very stable for awhile.

@trevnorris Is async_wrap in a stable enough state at this point that it'd make sense to start working on this?

[trevnorris]

@Qard Actually I'm trying to get it ready to be "public" API so have been working on several things. So I'd say expect more changes for the next little while, but also they'll most likely be smaller changes.

[Qard]

Yeah, I was aware there was some effort going into preparing it to go public, but I didn't know what that meant for short-term API stability. I'll take another look when it's ready to go public to see if I can get a decent polyfill put together. 😸

[joshgav]

closing old AsyncWrap issues, please start a new thread if appropriate