Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
libsubprocess: Support line buffering stdout/stderr #2262
To limit callbacks to the
Originally, I made this option to "enable" line buffering. But upon further investigation, everything in flux reads lines. So I enabled line buffering by default, but allow it to be disabled.
Lots of stupid cleanups/fixes along the way.
garlick left a comment
Couple minor suggestions.
You can prob merge the two commits containing inline doc fixes.
I find myself a bit lost without more detailed commit messages.
So what is the net effect on the I/O code in the shell? Fewer on_stdin, on_stdout callbacks when a read_line will just return 0 (and it's not eof yet)? On master I'm unable to prove to myself that this is happening right now. It was happening a lot before as I recall. Hmm, maybe I'm not checking the right thing.
In a number of tests, arguments were passed to ok() for output but no conversion specifies were specified in the output format. Remove this unnecessary arguments.
Add additional tests to test for the length of the data coming back from flux_subprocess_read_line().
Do not want an ENOMEM error logging to stderr, ENOMEM should simply be returned to the caller.
Refactor checks to determine if user set a BUFSIZE parameter. It can be called fewer times by moving the call to a common function.
Yup, you're exactly correct. We saw it in #2211.
One of the new tests I added shows it pretty well. I have something that outputs "hi" 2200 times and then outputs a newline (I picked 2200 b/c I wanted > 4096 bytes to pop out).
With line buffering turned on,
@@ Coverage Diff @@ ## master #2262 +/- ## ========================================== + Coverage 80.73% 80.74% +<.01% ========================================== Files 210 210 Lines 33224 33233 +9 ========================================== + Hits 26825 26835 +10 + Misses 6399 6398 -1