Skip to content

Flush the Backend buffer #691

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

Merged
merged 2 commits into from
Sep 28, 2022
Merged

Flush the Backend buffer #691

merged 2 commits into from
Sep 28, 2022

Conversation

kkysen
Copy link
Contributor

@kkysen kkysen commented Sep 26, 2022

Fixes #689.

Normally the BufWriter in LogBackend is flushed in drop, but since all of this runs from a static or a background thread, no destructors are run (reliably at least; not sure about the background thread case). Thus, we need to explicitly flush the buffer. I believe this may be the remaining cause of #613.

This fix adds a flush method to trait WriteEvent, which is called after all Events have been written so that we never lose any of the Events. It's implemented by delegating to Write::flush, both for BufWriter in LogBackend and stderr() in DebugBackend (though that one is usually unbuffered).

I discovered this while implementing #687, as the missing flush is reliably detected when running the Backend on the main thread.

…g all the `Event`s so that we never miss any.
@kkysen kkysen requested a review from aneksteind September 26, 2022 20:57
@kkysen kkysen force-pushed the kkysen/flush-backend-buffer branch from 283970a to 27d7cd4 Compare September 26, 2022 22:41
@kkysen kkysen merged commit 7e79f91 into master Sep 28, 2022
@kkysen kkysen deleted the kkysen/flush-backend-buffer branch September 28, 2022 03:06
@kkysen
Copy link
Contributor Author

kkysen commented Oct 10, 2022

I believe this (and #683) have finally fixed #613. I haven't noticed anymore flaky CI failures since. @aneksteind, have you noticed any? If not, I'll finally close that issue.

kkysen added a commit that referenced this pull request Oct 16, 2022
Fixes #687.

This adds a single (main) thread instrumentation runtime in addition to the existing background thread runtime.

The single-threaded, main thread runtime greatly simplifies the logic, helping to easily and quickly expose bugs, like #613, which I solved in #691 as soon as I added the single-threaded runtime.  This, I think, is the main motivation for adding this, though it may also be faster in certain cases, and would allow instrumented code to run in single-threaded environments in the future.

The runtime, like the backend, is dynamically selected through `$INSTRUMENT_RUNTIME`, which must be either `fg` for the main thread runtime, or `bg` for the background thread runtime.  This is exactly how `$INSTRUMENT_BACKEND` currently works for the backend.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flush the LogBackend BufWriter
2 participants