-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Add support for wrapping system streams in WorkRequestHandler #14201
Closed
Bencodes
wants to merge
1
commit into
bazelbuild:master
from
Bencodes:add-support-for-wrapping-system-streams-in-workrequesthandler
+237
−22
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Wrapping
System.err
isn't actually be necessary for a wrapper worker io.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.
Correct. Also
System.in
is already handled properly. OnlySystem.out
needs to be wrapped.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.
The motivation behind wrapping all of the system streams in a
WorkerIO
class is that there is a clear and consistent place to access the root system streams while setting up the work request handler. ForSystem.in
andSystem.err
we can just return the original streams when callinggetOriginalInputStream
.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.
Upon further reflection, what you do makes sense, but not in the way you use it in the example. Instead of wrapping the whole WorkRequestHandler, wrapping the inside of the WorkRequestCallback would be clearer. You wouldn't even need to have the accessors to the original streams. That prevents the tool from attempting to read from stdin and corrupting the communication.
That change would also mean that the WorkerIO doesn't need to reset the buffer, as it'll be thrown away once a request is done. Plus in case
processRequest
in your example throws an exception the WorkerIO will be closed properly.A definite benefit of either approach is that stdout and stderr get merged into a single stream, that will be easier to understand.
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.
By this do you mean calling
capture
from within the implementation ofWorkRequestHandler
, or in the lambda that gets passed into theWorkRequestHandler
? I like idea of this being hidden inside theWorkRequestCallback
because we hideWorkerIO#readCapturedAsUtf8String
entirely which is kind of an awkward API to need to expose.Would each work request call
WorkerIO#capture
swapping in it's own buffer?Wrapping the
stderr
could be a bit error-prone because if there's ever an unrecoverable error that causes the worker to not send a work response, you just won't see an exception come out of the worker.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.
@larsrc-google I took another pass at building this into the
WorkRequestHandler
so that it's a bit more transparent, and with the multiplex worker cases in mind. The new approach uses the existingWorkerIO
implementation, but wraps the system streams when you callWorkRequestHandler#processRequests
.The
WorkerIO
instance gets passed down intorespondToRequest
so that there is a single source of truth for the wrapped streams, and so that we don't have to deal with multipleWorkerIO
instances being created inside ofrespondToRequest
which doesn't really make sense in a multiplex-world whererespondToRequest
may get called concurrently.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.
Oh, I've been so focused on the implementation details that I forgot the larger problem: Redirecting the stderr messages into the
output
field of the response changes semantics. Theoutput
field is for shorter messages to be displayed to the user,stderr
goes into the logs. See https://docs.bazel.build/versions/main/creating-workers.html#work-responses. It's known that multiplex workers only have one log between them, but the messages shown to the user should not interleave.And of course, since the multiplex threads still share one
System.err
instance regardless of what we set, we can't possibly disentangle that. But we can still fix the main issue of stdout getting corrupted by setting it to the same stream as stderr.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.
Just to make sure i'm understanding next steps here - You'd prefer that we avoid capturing the tool output streams and instead just swap the
System.err
in forSystem.out
to not pollute the work response output?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.
Yes. Having System.err and System.out go to the same place (the logs) is good. Changing the work response output would cause a lot of noise.
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.
Pushed the changes for swapping
System.err
in forSystem.out
and updated the tests.