in reply to Re: IPC via named pipes, losing some messages
in thread IPC via named pipes, losing some messages

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;
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?

Replies are listed 'Best First'.
Re^3: IPC via named pipes, losing some messages
by ikegami (Patriarch) on Apr 11, 2008 at 10:40 UTC

    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.

      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...