in reply to IPC via named pipes, losing some messages

$| = 1; select(PIPE);
is wrong. It sets autoflush for the previously select handle, not PIPE. It should be
my $old_sel = select(PIPE); $|=1; select($old_sel);
or the more readable
use IO::Handle qw( ); PIPE->autoflush(1);

Now that won't fix your problem. Since you proceed to close the pipe after every print, everything is being flushed even though you fail to turn on autoflush. However, once you fix autoflush, you won't have any reason to keep reopening and closing the pipe.

Now, I'm quite curious as to what you use <PIPE> to read from the pipe (with $/ left to its default) when the data sent over the pipe doesn't contains any newlines.

Replies are listed 'Best First'.
Re^2: IPC via named pipes, losing some messages
by ftumsh (Scribe) on Apr 11, 2008 at 09:33 UTC
    I wan't sure about the autoflush, but I've tried it with and without all to no avail. Out of interest, wouldn't 
    select(PIPE); $| = 1;

    [download]
    work? fwiw as it's in a loop, wouldn't the second iteration turn it on?
    I digress...
    I don't understand your last paragraph. Could you explain it please?
[reply]
[d/l]

      It would work, but print statements without a file handle will now go into the PIPE instead of to STDOUT. That's probably not what you want to do, and I don't like using select that way (spooky action at a distance). That's why you should have a second select to re-select the currently selected handle.

      I don't understand your last paragraph. Could you explain it please?

      <FILE> reads until end of line, but your data doesn't contain lines.

[reply]
[d/l]
[select]
        Ah, I see. I think the closing of the pipe does it, so <PIPE> works.
        Well I say it works, it patently isn't working all the time. The first two code blocks in my post work as they should.
        I've just put a "|| die 'couldn't open';" on the open and it doesn't die, so that isn't the problem
        I was under the impression that it worked like this: server opens pipe. This blocks until there is data to read. client opens pipe, writes data, closes pipe. There is a chance that the server doesn't have the pipe open, ie it's servicing a request. (The server has some quick stuff to do, longer requests cause a fork and the main server returns to the event loop) If the server doesn't have the pipe open, the client blocks until the server opens the pipe. If the above is correct, I don't understand why my stuff is failing...
[reply]

In Section Seekers of Perl Wisdom