-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
callback is called synchronously #10
Comments
Thanks a lot for your comment. You are totally right and I am already working on a version with true async resolution of the custom types (witch will bring a lot more power to the library). I will be soon creating a brach with a draft of the new verion and you are more than welcome to check it out or contribute to it. I appreciate your input. Cheers |
@yortus Wouldnt using process.nextTick() solve the undefined callback issue? |
@ramikhalaf yes, but it wouldn't mitigate the starvation problem and dreamjs would still be effectively synchronous - see https://gist.github.com/brycebaril/ff86eeb90b53fd0c523e |
@yortus I agree, but i meant it as its just a temporary work around that gives the callback async behavior until the new version. |
Hi @adleroliveira,
Saw this at top of /r/node, congrats!
I noticed that dreamjs supports an async API but its implementation is fully synchronous. This will lead to errors in usage like the following:
The async callback model of node guarantees that the callback won't be called until the next turn of the event loop (at the earliest), so the example should be 100% safe.
It looks like your implementation does everything synchronously and calls the callback synchronously too, so the
useResult(result);
line gets called beforeuseResult
is defined, and an error ensues.More generally, there's no point offering callbacks/Promises/streams if the implementation is synchronous. The synchronous implementation completely starves the event loop until it finishes, so there is no opportunity for other code to run. I would suggest:
setImmediate
. When the full output is ready, then return the result through the callback/Promise/etc.As for which is best, I'd say it depends how much processing is likely to be involved in producing deamjs outputs. If it's no more than a millisecond or two in the worst case, you might as well just keep it synchronous.
On the other hand if you get people wanting to generate MBs of test data from this, that could take a while to generate. Your current implementation will starve the event loop even though the API 'looks' asychronous. In this case you should definitely break up the work as suggested above.
Again, nice lib, and that's just my 2c!
The text was updated successfully, but these errors were encountered: