Re^2: IPC via named pipes, losing some messages

Well with some ideas from above, I have tried:

local $/;
open PIPE, "<$pipe";
my $data = <PIPE>;
close PIPE;
[download]

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;
[download]

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?

Comment on Re^2: IPC via named pipes, losing some messages Select or Download Code

Replies are listed 'Best First'.
Re^3: IPC via named pipes, losing some messages by pc88mxer (Vicar) on Apr 14, 2008 at 15:37 UTC
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);` [download] I haven't yet found out how to make the `sysread` call blocking, but if I do I'll let you know.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: IPC via named pipes, losing some messages
by pc88mxer (Vicar) on Apr 14, 2008 at 15:37 UTC

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);
[download]

sysread

[reply]
[d/l]
[select]