Sisyphus <[EMAIL PROTECTED]> writes:
>
>I now find that, on the Linux box, if I write func_1() as:
>
>void func_1() {
> PerlIO_printf(PerlIO_stdout(),"SOMETHING");
> }
As I said
PerlIO_stdoutf("SOMETHING");
does that...
>
>then there's no need to do a PerlIO_flush(PerlIO_stdout()). It's already
>flushed for me.
This probably depends where STDOUT is going.
PerlIO does line buffering when STDOUT is a TTY.
(Console is considered a TTY on Win32.)
>
>It's only when I write func_1() as:
>
>void func_1() {
> printf("SOMETHING");
> }
>
>that I find there's a need to fflush(stdout).
Seems that, Win32's C runtime doesn't do UNIX-like "linebuffering"
(see below), or in PerlIO case your XS and perl just happily share one
buffer.
>
>Probably time for me to take a look at that C library function and how
>I've wrapped it.
>
>
> > (e.g., you're wrapping a C
>> library), then you need to set the stdio stdout stream to be unbuffered,
>> or at the very least, line buffered. do this before getting into your C
>> code, preferably.
>>
>> man setbuffer
>> man setlinebuf # probably on the same manpage
>>
>> /* set stdout unbuffered (is a performance hit!) */
>> setbuffer (stdout, NULL, 0);
>>
>
>I wonder .... does that have any advantage over doing a fflush(stdout) ?
probably not.
>
>> /* tell stdout to fflush() after every '\n' */
>> setlinebuf (stdout);
>
>Seems to me that stdout already gets a fflush() after every '\n' - so a
>setlinebuf(stdout) should not be necessary.
>
setlinebuf() is more subtle than that (or is supposed to be).
Yes it flushes on \n (but does not have to do a write() per \n if
more than one \n occurs in a print), but ALSO flushes line bufffered
streams when you read() from a TTY (think shell prompts which don't end with
\n but get flushed when shell reads from stdin).
