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
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).
On Wed, Feb 28, 2001 at 10:23:06PM -0500, Adi Fairbank wrote:
> Delivered-To: [EMAIL PROTECTED]
> Date: Wed, 28 Feb 2001 22:23:06 -0500
> From: Adi Fairbank <[EMAIL PROTECTED]>
> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586)
> X-Accept-Language: en
> To: Sean Chittenden <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> Subject: Re: mod_perl shared memory with MM
>
> Sean,
>
> Yeah, I was thinking about something like that at first, but I've never played
> with named pipes, and it didn't sound too safe after reading the perlipc man
> page. What do you use, Perl open() calls, IPC::Open2/3, IPC::ChildSafe, or
> something else? How stable has it been for you? I just didn't like all those
> warnings in the IPC::Open2 and perlipc man pages.
>
> -Adi
>
> Sean Chittenden wrote:
> >
> > The night of Fat Tuesday no less... that didn't help any
> > either. ::sigh::
> >
> > Here's one possibility that I've done in the past becuase I
> > needed mod_perl sessions to be able to talk with non-mod_perl
> > programs. I setup a named bi-directional pipe that let you write a
> > query to it for session information, and it wrote back with whatever
> > you were looking for. Given that this needed to support perl, java,
> > and c, it worked _very_ well and was extremely fast. Something you
> > may also want to consider because it keeps your session information
> > outside of apache (incase of restart of apache, or desire to
> > synchronize session information across multiple hosts).
> >
> > -sc
> >
>
--
Sean Chittenden [EMAIL PROTECTED]
PGP signature
