-
Notifications
You must be signed in to change notification settings - Fork 78
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
async_wrap: error handling #7
Comments
Initial implementation will be super basic. You can set an Also we can't guarantee a handle can be properly cleaned up because if |
I wasn't expecting automatic handle cleanup. Using I was just wondering if it's possible to have something like |
@Qard The point is that you can't safely call |
This cleanup strategy is conceptually okay but in practice it doesn't work; if you close the handle but the stream that manages it isn't aware it gets into a weird state. I would suggest to allow "resources" (e.g. streams but also child processes) to register a cleanup hook that gets called when the containing domain/context/wrap errors/throws. This is basically the strategy I used for zones as well. |
@piscisaureus problem there is that we'd have to make sure all internal resources are properly cleaned up as well. I'm thinking specifically from the C++ side of things. |
Ah, I understand now. Maybe we could represent those things from allocator classes that could attempt to free after the call or get manually freed from the close in JS, if not automatically freed already? I'm a bit uncomfortable with the idea of managing memory from JS though... |
@Qard spoke w/ @piscisaureus about it. we thought that it was a good idea to get away from this way of allocating resources anyway. though we'll have to actually visit the implementation to judge feasibility. |
closing old AsyncWrap issues, please start a new thread if appropriate |
I'd like people to share their views/needs/questions/concerns on error handling with async_wrap.
Given the availability of handles within event handlers: could one use it, along with process._fatalException, to close active handles within a failed domain?
At what stages of a call could a handle be safely terminated?
The text was updated successfully, but these errors were encountered: