On Mon, Mar 12, 2001 at 12:14:26PM -0800, Sean Chittenden wrote:
> Sorry for taking a while to get back to this, road trips
> can be good at interrupting the flow of life.
>
> It depends on the application. I typically use a few
> instances of open() for the sake of simplicity, but I have also had
> decent luck with IPC::Open(2|3). The only problems I've had with
> either was an OS specific bug with Linux (the pipe was newline
> buffering and dropping all characters over 1023, moved to FreeBSD and
> the problem went away).
>
> Words of wisdom: start slow because debugging over a pipe can
> be a headache (understatement). Simple additions + simple debugging =
> good thing(tm). I've spent too many afternoons/nights ripping apart
> these kinds of programs only to find a small type-o and then
> reconstructing a much larger query/response set of programs. -sc
<plug>
If you're working with Open{2,3}, you might want to take a gander at
IPC::Run, it's like Open{2,3,...}+select loop+expect, but with a
shell-like API and the ability to trace events in both the parent and
child processes (via a separate debugging pipe). Just turn debugging on
and you can see what's sent and received on each pipe. It avoids the
deadlocks warned about in the perlipc manpages (as you mention), which
can be quite tricky in the face of different failure modes. IPC::Run
establishes or manages pipes, PTYs, plain ol' filehandles and timers in
such a wayavoid deadlocks (though if you try hard engugh...).
It's a bit bloated to do all that, but the debugging feature can make it
worth the bloat in many cases, and you can certainly rename it and carve
off great hunks of unneeded features (like param parsing or say ptys)
pretty easily if you want to whittle it down after debugging.
That being said, open2 and open3 are for forking around, not for
communicating over named pipes to server processes.
</plug>
> PS You also want to attach the program listening to the named
> pipe to something like DJB's daemon tools
> (http://cr.yp.to/daemontools.html) to prevent new requests from
> blocking if the listener dies: bad thing(tm).
Neat, thanks for that link.
- Barrie
