in reply to IPC via named pipes, losing some messages

I see a problem with repeatedly opening and closing the pipe and using buffered I/O:
while (1) { ... open FH, "<pipe"; my $data = <FH>; close FH ... }
I would open the pipe outside the while loop. When you using buffered I/O (ala <FH>) you can read more than one line from the pipe even though only one line is returned by <FH>. The rest is buffered by perl, but since you are closing the pipe right away it essentially is discarded. This could account for why the server is not logging all of its reads.

Replies are listed 'Best First'.
Re^2: IPC via named pipes, losing some messages
by ftumsh (Scribe) on Apr 14, 2008 at 08:42 UTC
    Well with some ideas from above, I have tried:
    local $/; open PIPE, "<$pipe"; my $data = <PIPE>; close PIPE;
    Which didn't work, I'm still missing some messages. So, assuming the problem is with buffered IO, I thought I'd try:
    open FH, "<$config->{'pipe'}"; my $data; while (sysread FH, my $buf, 2048) { $data .= $buf; } close FH;
    Which is also not working. I am stumped. I could open the pipe out of the loop, but then it wouldn't block on the open and I'd rather not sleep to simulate that. Any ideas?
      I think you're better off using a socket based approach. Then you'll have a separate file handle for every connection. By closing and re-opening the pipe you introduce a race condition and (at the very least) run the risk of causing SIGPIPE signals to be sent to the client processes. (And maybe this is what is happening since your clients are logging the message being sent before writing it to the pipe.)

      That said, does this work for you?

      open FH, "<pipe" or die "open failed; $!\n"; my $buf; while (1) { my $nr = sysread(FH, $buf, 1024, length($buf)); while ($buf =~ s/^(.*?)\n//) { process_line($1); } sleep(1); } close(FH);
      I haven't yet found out how to make the sysread call blocking, but if I do I'll let you know.