[erlang-questions] Flush "stdout" buffer

[Frank Muller]

Ok, thanks for the clarification.

/Frank

Le sam. 2 sept. 2017 à 19:15, Michael Truog <mjtruog@REDACTED> a wrote :

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170902/1b400cce/attachment.htm>