-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Questions: async_hooks destroy callback vs setImmediate #13262
Comments
Thanks for this report! I suspect this has something to do with the |
@addaleax , Thank you for reply, got it! I will continue to test other async APIs. |
Indeed, we can't always guarantee the The emit is queued using I guess we can check the |
Looking at how |
This seems like a simple bug: |
@Fishrock123 it already is "emitted" in |
Run destroy callbacks before a normal application exit happens. Fixes: nodejs#13262
Calling the destroy callbacks in a uv_idle_t causes a timing issue where if a handle or request is closed then the class isn't deleted until uv_close() callbacks are called (which happens after the poll phase). This results in some destroy callbacks not being called just before the application exits. So instead switch the destroy callbacks to be called in a uv_timer_t with the timeout set to zero. When uv_run() is called with UV_RUN_ONCE the final operation of the event loop is to process all remaining timers. By setting the timeout to zero it results in the destroy callbacks being processed after uv_close() but before uv_run() returned. Processing the destroyed ids that were previously missed. Also, process the destroy_ids_list() in a do {} while() loop that makes sure the vector is empty before returning. Which also makes running clear() unnecessary. Fixes: nodejs#13262 PR-URL: nodejs#13369 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Verify that the destroy callback for a TCP server is called before exit if it is closed in another destroy callback. Fixes: nodejs#13262 PR-URL: nodejs#13369 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Calling the destroy callbacks in a uv_idle_t causes a timing issue where if a handle or request is closed then the class isn't deleted until uv_close() callbacks are called (which happens after the poll phase). This results in some destroy callbacks not being called just before the application exits. So instead switch the destroy callbacks to be called in a uv_timer_t with the timeout set to zero. When uv_run() is called with UV_RUN_ONCE the final operation of the event loop is to process all remaining timers. By setting the timeout to zero it results in the destroy callbacks being processed after uv_close() but before uv_run() returned. Processing the destroyed ids that were previously missed. Also, process the destroy_ids_list() in a do {} while() loop that makes sure the vector is empty before returning. Which also makes running clear() unnecessary. Fixes: #13262 PR-URL: #13369 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
Version:
v8.0.0-nightly20170527f84666f923
Platform:
Mac OS
Subsystem:
I just tried the new
async_hooks
callback API, I want to confirm the behaviors below is correct or not?It is just a simple
setImmediate
and it was clear byclearImmediate
.I expect the result will be
but the result is
only.
If I add some other
setTimeout
logic in the test program, thedestroy
will be called.the result will look like
Is this the correct behaviors? And how to ensure the
destroy
callback is called ?Thanks a lot!
The text was updated successfully, but these errors were encountered: