-
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
src: cherry-pick from downstream, worker prep #15707
Conversation
Original PR: ayojs/ayo#82 > This makes some of the internal `AsyncWrap::MakeCallback()` > utility wrappers throw rather than crash the process when > the requested method is not present on the `this` object. > Doing so makes it easier for future code to expose C++ > objects directly to userland, where JS code can overwrite > or delete such methods. > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
Original PR: ayojs/ayo#82 > Previously, the `Environment` destructor did not release its > `fs_stats_field_array` memory. The memory is allocated when the > `fs` module is initialized and calls `GetStatValues()`. > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
Original PR: ayojs/ayo#82 > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
Original PR: ayojs/ayo#82 > This adds pairs of methods to the `Environment` class and to public APIs > which can add and remove cleanup handlers. > Unlike `AtExit`, this API targets addon developers rather than > embedders, giving them (and Node’s internals) the ability to register > per-`Environment` cleanup work. > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
Original PR: ayojs/ayo#82 > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
Original PR: ayojs/ayo#82 > PR-URL: ayojs/ayo#82 > Reviewed-By: Stephen Belanger <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Why were the changes to string_search.{cc,h} made in 53d6465? Shouldn't that have been a separate commit? |
@jasnell I don’t think I can approve these changes as the author :) |
Likely, but I didn't make those changes so I cannot say for certain
No, but you can, if you'd like, review them for completeness :-) If you wouldn't mind. |
Ping @nodejs/collaborators |
How are we copyright-wise for this? |
Assuming this counts as a derived work of the original code and since it shares the same license headers, I wouldn't expect this to be a problem in terms of copyright..? This is copying public code under MIT w/o changing the license. P.S.: If Anna would prefer not pulling this in, we should respect that of course. But that's goes beyond copyright. :) |
There should be absolutely zero copyright issue here at all. |
Can we have a short post implementation eps? What's the motivation? What the key implementation principles? I saw some |
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.
Introducing Mutex
es and threads without any userland implementation, test coverage or correctness proof.
I know this is an "obscure" CR, but it's also an abstract change set.
It's just Also, this is just preliminary work. There's no implementation yet because it needs these bits to even be possible. Test coverage will be included with the implementation, when it's ready. |
In that case I'm not sure what is the benefit? |
If it actually got reviewed that'd be fine, but the previous workers PR was left for literally years without proper review. It's a really big feature. Delivering it all in one neat package is a huge undertaking. It needs to happen in stages or it'll just never happen. |
For reference, the worker PR itself is ayojs/ayo#58. These commits were picked out of that to separate PRs because it was difficult to review such a large block of code all at once. |
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 believe some of this should move to libuv
}); | ||
} | ||
|
||
void Environment::IncreaseWaitingRequestCounter() { |
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.
AFAICT this is supposed to proxy the status of the libuv
. If I'm correct IMHO it should be a libuv
API.
libuv/libuv#1528 seems like a good start.
Diving in and starting to figure out some bits. It seems to me this PR as is, does benefit the use-case of embedding node into an MT process, but I'm deducing this from the code. IMHO it would help if it came with some explanations and motivation. |
@refack Yes, maybe that should have ended up in commit messages |
Oops, pressed enter too early. Anyway, maybe the commit messages for adding mutexesshould have provided motivation, but I think you can basically deduce from “add mutexes to previously single-threaded code” what you did deduce from it. Also, yes, I’m fine copyright-wise. And re: completeness … I see nothing missing here, but since the work in Ayo.js is not complete, it’s hard to make a statement on that. |
I still think the single-process approach is a fundamentally bad idea for reasons of robustness and portability, see #13143 (comment) for background. The multi-process approach on the other hand is something I could get behind. |
I can get behind this change if we I'll try to do that bit (while I'm not at #Interactive :( ) |
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.
These changes generally LGTM and I ran the code (in Ayo) and it worked fine. I'm not sure I'm the right person to weigh in on the code but the code changes themselves lgtm
uv_cancel(reinterpret_cast<uv_req_t*>(&req_)); | ||
} | ||
|
||
/* Below is dark template magic designed to invoke libuv functions that |
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.
This is fairly standard C++, I'm not sure why it consists of magic but I like the explanation. I'm a little surprised this works on all Node's compile targets though.
req(), | ||
MakeLibuvRequestCallback<T, Args>::For(this, args)...); | ||
if (err >= 0) | ||
env()->IncreaseWaitingRequestCounter(); |
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 think it's worth commenting that err < 0
always implies that the callback won't be called, so we don't decrease/increase the waiting request counter.
This needs a rebase due to many conflicts and I think there was some further progress in ayo about this that should also be included in the update. |
I'm going to close this for now and will revisit again later on. |
Cherry-pick of downstream ayo commits.
PR: ayojs/ayo#82
PR: ayojs/ayo#85
/cc @addaleax
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
src, async_wrap, cares