You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Sean Chittenden <se...@chittenden.org> on 2001/03/01 03:28:21 UTC

Re: mod_perl shared memory with MM

	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

On Wed, Feb 28, 2001 at 09:25:45PM -0500, Adi Fairbank wrote:
> Delivered-To: sean@chittenden.org
> Date: Wed, 28 Feb 2001 21:25:45 -0500
> From: Adi Fairbank <ad...@certsite.com>
> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586)
> X-Accept-Language: en
> To: Sean Chittenden <se...@chittenden.org>
> Subject: Re: mod_perl shared memory with MM
> 
> It's ok, I do that a lot, too.  Usually right after I click "Send" is when I
> realize I forgot something or didn't think it through all the way. :)
> 
> Sean Chittenden wrote:
> > 
> >         Hmm... yeah, whoops.  I suppose that's what I get for sending
> > email that late.  <:~) -sc
> >
> 

-- 
Sean Chittenden                sean@chittenden.org
C665 A17F 9A56 286C 5CFB  1DEA 9F4F 5CEF 1EDD FAAD

Re: mod_perl shared memory with MM

Posted by "Alexander Farber (EED)" <ee...@eed.ericsson.se>.
Adi Fairbank wrote:
> 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

IPC:ChildSafe is a good module, I use it here to access ClearCase, but 
it probably won't help you to exchange any data between Apache children

Re: mod_perl shared memory with MM

Posted by barries <ba...@slaysys.com>.
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

Re: mod_perl shared memory with MM

Posted by Sean Chittenden <se...@chittenden.org>.
	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: sean@chittenden.org
> Date: Wed, 28 Feb 2001 22:23:06 -0500
> From: Adi Fairbank <ad...@certsite.com>
> X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i586)
> X-Accept-Language: en
> To: Sean Chittenden <se...@chittenden.org>
> CC: modperl@apache.org
> 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                sean@chittenden.org

Re: mod_perl shared memory with MM

Posted by Adi Fairbank <ad...@certsite.com>.
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
>