Async API

[kjvalencik]

Any plans for an async API? Any road blocks that you would anticipate?

Great module! Cheers.

[jonathanmarvens]

@kjvalencik Can you please clarify what you mean by “an async API”?

[kjvalencik]

Maybe I'm missing something (I'm a noob at Rust), but there doesn't appear to be a way to safely accept a callback, grab a libuv thread for execution and stop blocking the event loop.

https://github.com/nodejs/nan#nancallback

If it is possible, an example would be excellent! Thanks.

[dherman]

Yep, we'll definitely need something like that. One of my near-term plans is to sketch up an API road map.

[Drakulix]

Whats the current Status on this and how would you like to see this implemented?
This is the biggest blocker for using Neon for me, so if I can help you with, I am happy to do so.

It mostly comes down to, how you would like to see Callback and AsyncWorker to be interfaced by Rust. Especially AsyncWorker is really tricky.

[dherman]

@Drakulix I'm getting ready to start looking into this, but I haven't used Nan's AsyncWorker etc. Can you help get me up to speed? Where should I go to learn more about them (other than the API docs, of course)?

[bnoordhuis]

@dherman If you have questions, I should be able to answer them.

[kamicut]

@dherman Maybe this resource is useful? http://blog.scottfrees.com/c-processing-from-node-js-part-4-asynchronous-addons

[netgusto]

Maybe would it be possible by chaining scopes like this:

nodejs -> Nan[dispatch-async-stuff] -> neon[process-sync-stuff] ?

[loyd]

What is the current status on this?

[dherman]

@loyd It's working its way up my priority queue but not at the top just yet—I've been focused on Electron support first. I haven't dropped this but can't give an ETA just yet, I'm afraid…

[kjvalencik]

I think this is implemented by #214 and can be closed.