Synchronisation of stdin, stderr
My log shows massive delays in output. For example:
Processing [82/84]: tut_16.flx
Processing [83/84]: tut_17.flx
Processing [84/84]: tut_18.flx
Batch result (83 OK + 01 FAIL)/84
[flx] Output C:\Users\appveyor\.felix\cache\text\C\projects\felix\build\release\test\tut\arithmetic.stdout doesn't match expected C:\projects\felix\build\release\test\tut\arithmetic.expect
The message here refers to test #1 but only enters the log after all 84 the tests are complete.
This doesn't happen on my personal windows box. I'm using C FILE* for output. Most of the writes to stdout
are followed by a fflush. Stderr is supposed to be unbuffered. Therefore the output should be synchronised.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Feodor Fitsner on 12 Oct, 2015 08:33 PM
AppVeyor uses the same pipe for collecting StdOut and StdErr, so I guess you see the output in the same order it comes to that pipe.
2 Posted by skaller on 12 Oct, 2015 09:29 PM
I see. However that ordering is not the same as I see in a CMD
console on Win10.
Usually, one assumes stderr is unbuffered, and stdout is buffered.
These are C level attributes, the OS may also have buffering
on top of that.
I have switched my program so “write a line to stdout” writes
and then does a fflush. So I guess what I am seeing
is the stderr is coming out long after stdout. Usually its the
other way around.
In other words the C stderr is in fact buffered.
Interesting. In C++, cout and cerr are *required* by default
to be tied (i.e. they have to go to the same ostream).
Ok, so I will have to fflush stderr as well.
Thanks!
Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:00 AM.