Skip to content

Conversation

@theodegeest
Copy link

This PR adds an explicit fflush(stdout) after printing the headers in the libbpf-tools offcputime example.

I am using this example as a dependency in another tool, where I monitor its standard output to determine when the tracer has successfully attached to a target process. Without an explicit flush, the header output appears to remain buffered and is never observed by the parent process, even after attachment.

By flushing stdout immediately after printing the headers, we ensure that the output is actually written once the tool has attached, making the behavior more reliable when stdout is being monitored or redirected. This change does not affect normal interactive usage but improves correctness in non-interactive and programmatic use cases.

Signed-off-by: theodegeest <theo.degeest@gmail.com>
Copy link
Collaborator

@ekyooo ekyooo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes the header output, but the same buffering issue could occur with other outputs during execution. Also, for standalone usage, this flushing is unnecessary.

Have you considered using unbuffer instead of modifying the code?

# unbuffer offcputime

I'm curious - could you share more about your use case for redirecting offcputime's stdout?
Thank you.

@theodegeest
Copy link
Author

I have tried using unbuffer. While this does solve the buffering issue, now I encounter a second one. I need to tell offcputime to stop. I do this by sending a kill signal. However, if the offcputime were to be wrapped by an unbuffer, then the kill signal wouldn't be sent to offcputime, but to unbuffer, resulting in an undesired behavior.

You mentioned that the same buffering issue occurs with other outputs as well. And for this, I agree. In my use case, it isn't all that important because I wait for the process to end. So it can be buffered.

I am using the offcputime tool in Benchkit, a benchmarking tool. In that project, I defined the offcputime tool as an attachment to any arbitrary benchmark to monitor its off-cpu-time behavior. More specifically, I hope to monitor the load imbalance of multithreaded benchmarks using this attachment.

Here is the actual implementation of this attachment, if you were interested.

Have a nice day.

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.

2 participants