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
