-
Notifications
You must be signed in to change notification settings - Fork 97
src: clean up handles (preparation for workers) #85
Conversation
Previously, handles would not be closed when the current `Environment` stopped, which is acceptable in a single-`Environment`-per-process situation, but would otherwise create memory and file descriptor leaks.
This allows easier tracking of whether there are active `ReqWrap`s.
src/req-wrap-inl.h
Outdated
fn, | ||
env()->event_loop(), | ||
req(), | ||
MakeLibuvRequestCallback<T, Args>::For(this, args)...); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm misreading, but doesn't MakeLibuvRequestCallback<...>::For(...)
make the callback variadic, not the call? For
is just returning a single T
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sooo … I am not sure I’m getting the question right 😄 What this does is write MakeLibuvRequestCallback<T, Args>::For(this, ?)
for every arg ?
in args
.
http://en.cppreference.com/w/cpp/language/parameter_pack#Pack_expansion can explain this better than I can :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh...I get it now. Thanks for the clarification.
Perhaps all that template wizardry could use some more elaborate comments? I suspect a lot of people less familiar with C++ templates will look at that stuff and have no idea what is going on. 🙀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of core could use more comments tbh.
Unfortunately, the template wizardry isn't just ours alone - we simply won't ever fully get away from V8's liberal use of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having a history of poorly documented code doesn't mean we should keep poorly documenting code.
Also, I don't think the V8 comparison quite fits here. The consuming side of the API is fine, it's what is going on behind the scenes that is confusing. Unlike V8, we have to maintain this code entirely ourselves, so it's important we make it understandable to anyone whom may need to work on it in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I’ve added a comment here that should help a bit – @Qard maybe take a look whether this is clear enough :)
One problem here is that this is very subjective – from my perspective what V8 does seems like nothing :) So yes, I really appreciate these comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that should be fine. I just want us to get in the habit of making the design of things in core clearer as that will make it a lot more accessible to potential new contributors. There are many people whom could make meaningful contributions to the native code, but don't have a lot of native dev experience or perhaps just haven't worked with C++-specific things like templating. 😸
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree 100 % :) It might be nice to write something along the lines of a tutorial for contributing to the native side of things … even people who are used to writing C++ have a bit of a hard time adjusting to the way the V8 API works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I started working on some Node.js internals docs a few years ago, which I believe are still in the website repo somewhere. I don't think they are exposed in navigation though and could probably be updated and expanded.
Workers cannot shut down while requests are open, so keep a counter that is increased whenever libuv requests are made and decreased whenever their callback is called.
9b80626
to
a42c922
Compare
MacOS CI should be good now :) |
Previously, handles would not be closed when the current `Environment` stopped, which is acceptable in a single-`Environment`-per-process situation, but would otherwise create memory and file descriptor leaks. PR-URL: #85 Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
This allows easier tracking of whether there are active `ReqWrap`s. PR-URL: #85 Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Workers cannot shut down while requests are open, so keep a counter that is increased whenever libuv requests are made and decreased whenever their callback is called. PR-URL: #85 Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Landed in 1f66e8b...c4663f3 :) |
Original PR: ayojs/ayo#85 > Previously, handles would not be closed when the current `Environment` > stopped, which is acceptable in a single-`Environment`-per-process > situation, but would otherwise create memory and file descriptor > leaks. > PR-URL: ayojs/ayo#85 > Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Original PR: ayojs/ayo#85 > This allows easier tracking of whether there are active `ReqWrap`s. > PR-URL: ayojs/ayo#85 > Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Original PR: ayojs/ayo#85 > Workers cannot shut down while requests are open, so keep a counter > that is increased whenever libuv requests are made and decreased > whenever their callback is called. > PR-URL: ayojs/ayo#85 > Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Previously, handles would not be closed when the current `Environment` stopped, which is acceptable in a single-`Environment`-per-process situation, but would otherwise create memory and file descriptor leaks. Also, introduce a generic way to close handles via the `Environment::CloseHandle()` function, which automatically keeps track of whether a close callback has been called yet or not. Many thanks for Stephen Belanger for reviewing the original version of this commit in the Ayo.js project. Refs: ayojs/ayo#85 PR-URL: #19377 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
This allows easier tracking of whether there are active `ReqWrap`s. Many thanks for Stephen Belanger for reviewing the original version of this commit in the Ayo.js project. Refs: ayojs/ayo#85 PR-URL: #19377 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
Workers cannot shut down while requests are open, so keep a counter that is increased whenever libuv requests are made and decreased whenever their callback is called. This also applies to other embedders, who may want to shut down an `Environment` instance early. Many thanks for Stephen Belanger for reviewing the original version of this commit in the Ayo.js project. Fixes: #20517 Refs: ayojs/ayo#85 PR-URL: #19377 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
Also split out from #58
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
src