[erlang-questions] Flush "stdout" buffer

[Michael Truog]

On 09/02/2017 04:08 AM, Per Hedeland wrote:
> On 2017-09-02 10:07, Michael Truog wrote:
>> On 09/01/2017 04:58 AM, Frank Muller wrote:
>>> Can someone help on this please?
>>>
>> If you use stdout as an Erlang port like:
>>
>> STDOUT =  erlang:open_port({fd, 0, 1}, [out, {line, 256}]),
>> erlang:port_command(STDOUT, "unbuffered").
>
> Can you actually observe a difference *in buffering* between doing that
> and just
>
> io:format("unbuffered").

Yes, it really does matter.  You will notice that the io module doesn't have any flush function, so you are unable to force any buffering in the Erlang VM to flush.  However, if you really care about stdout in unbuffered mode, you need to use the Erlang port as described above.  That is similar to using fcntl to set file descriptor 1 with O_NONBLOCK.  Programming languages normally have a way of setting stdout (and stderr, though stderr is really suppose to always be in unbuffered mode) in an unbuffered mode so all the output is available as quickly as possible.  An example for C++ is:

setbuf(stdout, NULL);
std::cout.setf(std::ios::unitbuf);

If you have pipes setup to handle stdout/stderr from a forked OS process that is executing a programming language, you want to have stdout and stderr in unbuffered mode to ensure the output is available without any extra delays (e.g., for logging).  Otherwise, it is problematic if the OS process crashes, because you may never receive a stacktrace (if one is provided) or any other output if it is available.

That is why each external (running in an OS process, not in the Erlang VM) CloudI API implementation (https://github.com/CloudI/CloudI/tree/develop/src/api) puts stdout and stderr into unbuffered mode.  In Erlang source code we can't really put the io server into an unbuffered mode, and there is no reason to really, because it is simpler to bypass the io server by making an Erlang port, as shown above.

Best Regards,
Michael