-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Preparation for the new background poller 'epollbg' #17244
Conversation
and get rid of the dependency loop on the grpc shutdown path. Make sure all background closures are complete before shutting down the other grpc modules. Avoid using the backup poller in TCP endpoints if using the background poller.
|
|
|
|
The test failures are because we forget to update iomgr_windows.cc etc. Add the missing changes now. |
|
|
|
|
|
|
|
|
GRPC_CLOSURE_INIT(&tcp->write_done_closure, | ||
tcp_drop_uncovered_then_handle_write, tcp, | ||
grpc_schedule_on_exec_ctx); | ||
if (grpc_event_engine_run_in_background()) { |
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.
Since this will be constant once the code has started, can this information be memoized rather than having to continuously call a virtual 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.
In retrospect, I think my comment here was misguided because this isn't an actual virtual function after all. It lives in the vtbl but is just a boolean, and I hadn't noticed that at first.
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.
So I think it should be fine to call grpc_event_engine_run_in_background() in the if condition, right? Given that grpc_event_engine_run_in_background() only accesses a boolean member of a global struct, it should not be very costly.
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.
Done. Revert the last two commits.
…s in background or not
|
src/core/lib/iomgr/tcp_posix.cc
Outdated
|
||
static bool event_engine_run_in_background = | ||
grpc_event_engine_run_in_background(); | ||
if (event_engine_run_in_background) { |
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 this is going to compile down to a lock / call / unlock . Can this memoization be done in the plugin initialization instead?
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.
Sorry, I think your previous version was right and my comment was misguided. I just realized that this wasn't a real virtual call even though it's in a vtbl.
|
|
|
This reverts commit c1af11f.
…gine runs in background or not" This reverts commit 9bbda89.
|
|
|
|
|
|
|
|
New flaky test: |
Extend ev_posix.* to prepare for the new background poller 'epollbg',
and get rid of the dependency loop on the grpc shutdown path. Make sure
all background closures are complete before shutting down the other grpc
modules.
Avoid using the backup poller in TCP endpoints if using the background
poller.