On Jul 13, 2004, at 1:06 AM, Sisyphus wrote:
#$| = 1; #makes no difference
$| has no effect on stdio's printf(), only on *perl*'s print ops. if you want $| to affect print statements from your xs code, you need to use perlio from your xs code.
if you cannot change the c code to use perlio
That, in conjunction with the elaboration provided subsequently by Nick, led me to consider changing the C code in the Inline C script.
I now find that, on the Linux box, if I write func_1() as:
void func_1() {
PerlIO_printf(PerlIO_stdout(),"SOMETHING");
}then there's no need to do a PerlIO_flush(PerlIO_stdout()). It's already flushed for me.
It's only when I write func_1() as:
void func_1() {
printf("SOMETHING");
}that I find there's a need to fflush(stdout).
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) ?
/* 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.
Cheers, Rob
--
Any emails containing attachments will be deleted from my ISP's mail server before I even get to see them. If you wish to email me an attachment, please provide advance warning so that I can make the necessary arrangements.
