Re: portable IPC::Run (was: "Re: select()/poll() on Win32: ...")

On Tue, Jan 30, 2001 at 03:35:27PM -0500, Rocco Caputo wrote:
> On Mon, 29 Jan 2001 22:56:23 -0500, barries wrote:
> >
> >In fact, I would be happy to port IPC::Run to Event or POE were either
> >cross platform wrt events on filehandles of all stripes and timers.  I
> >gave some thought to doing that anyway (see archives for spoor) and
> >there's been no demand from anyone for it, so never bothered.
> 
> There's a real need for event-driven IPC::Run.

On Win32, you mean?  On select() capable platforms, IPC::Run is both
scriptable, vaguely like Expect, and/or event driven.  By this I mean
you can call the event loop routine (pump()) or you can call run() or
finish() to go into the event loop until children are done.

> In response to requests, I added something similar to POE 0.1203 at
> the end of December.
> 
> My work-around for not being able to select() pipes on Win32 was a
> byproduct of writing portable pipe classes.  The classes try pipe(),
> socketpair() and finally fall back to IO::Socket::INET.  The last
> option makes conduits that seem to work fine with select() on MSWin32.
> I have no idea how well (or if) the fork/exec parts work, though.  For
> that matter, what about SIGCHLD?

All unexplored territory for me.  I considered using tcp sockets to/from
the child process for IPC::Run, and that's probably the fallback plan
for porting vcp to Win32 if the PerlIO select() or poll() effort fails.
Thanks for the suggestions, and...

> 
> POE::Pipe::OneWay and ::TwoWay will work without the rest of the
> library, and they make plain old filehandles via Symbol::gensym().
> Maybe they should be split out into a separate distribution?

Perhaps they should.  I wouldn't mind using them in IPC::Run on Win32,
again as a backup plan.

- Barrie