Skip to content
This repository has been archived by the owner on Oct 13, 2018. It is now read-only.

Async variants of functions are not actually asynchronous #80

Open
webmakersteve opened this issue Aug 3, 2016 · 1 comment
Open

Async variants of functions are not actually asynchronous #80

webmakersteve opened this issue Aug 3, 2016 · 1 comment

Comments

@webmakersteve
Copy link
Contributor

This isn't an issue for me, because I don't use the asynchronous versions of parse or serialize, but the methods themselves are deferred, not asynchronous.

Node only runs thinks on separate threads when they are designated to run in the event loop. Generally these are I/O tasks, like file system operations or network operations. By putting the code in process.nextTick we simply defer the code to execute when the event loop gives the CPU space to run code in the v8 thread again, just deferring the synchronous execution.

This seems like something that an implementer would do rather than something that should be baked into the library. Data serialization and parsing is generally a synchronous concern.

If you do want to make this truly asynchronous, the C++ code would need to spin up another thread and return the data when it's done. See Nan::AsyncWorker.

But since parsing and serialization generally takes under 1 ms anyway, there are not many benefits to offloading the parsing to another thread unless you are dealing with a large amount of data and do not want it to block. But in the current implementation it will still block, just on the next process tick.

Just something to think about.

@rynz
Copy link

rynz commented Aug 4, 2016

It looks like Nan::AsyncWorker is an abstraction of uv_queue_work(). Definitely a good idea to implement this suggestion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants