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

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.

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

Replies are listed 'Best First'.
Re^4: IPC via named pipes, losing some messages by ftumsh (Scribe) on Apr 11, 2008 at 11:05 UTC
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]

Replies are listed 'Best First'.

Re^4: IPC via named pipes, losing some messages
by ftumsh (Scribe) on Apr 11, 2008 at 11:05 UTC

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]