[Phoenix-pm] Looking for ideas - Perl Telnet Monitor

[aj@exiledplanet.org]

Aha!  A possible solution emerges!  Though I've forgotten what coroutines are.  :-(

--aj

Scott Walters <scott at illogics.org> wrote:
__________
>Ahhh... okay, this is just a fragment, but it sounds like you're having the 
>standard problem of needing to monitor multiple IO handles -- in this case, at
>least one user and one program launched for the user by the daemon. 
>
>select() was designed for this, but it's painful for anything beyond trivial
>applications.  All operations must be atomic and must return back to the
>"select loop".  Hence things like POE were created.  POE also has an event
>loop which is little more than a select loop, but you're still restricted
>to atomic operations that can't block or perform additional IO operations
>in response to the one that just completed and must instead schedule them
>for the future.  You also don't get any variables that persist between
>these atomic operations -- all of your data must be instance data or else
>it's lost when you return back to the event handler.  This is only marginally
>better than a plain select loop.  Perl's threads are unusable for any
>case where the threads must share data or else they'd get the recommendation,
>but for applications like this, I strongly advocate the Coro module.  In
>fact, there are two chapters on it in _Perl 6 Now_ [blatent self-plug
>alert].  
>
>Used like this, Coro provides essentially cooperative multithreading.  You'd 
>still need IPC::Open2/IPC::Open3.  Coro has a method to convert regular
>file handles, such as those returned by IPC::Open2, into something that knows
>how to cede the CPU rather than block on data.  
>
>The structure would be something like this:  a listener loop accepts connections
>and creates a coroutine (the command prompt) for each connection accepted.  The
>command prompt accepts commands (obviously) and creates coroutines for each
>command that doesn't complete instantly.  These command coroutines use 
>IPC::Open2 or IPC::Open3 to open bi-directional or tri-directional pipes to 
>whichever system command is to be run (use the syntax that avoids invoking the
>shell!).  The command coroutines, after setting up the pipe, perform filtering
>on the data, applying any coloring or highlighting.  If a -more- prompt is 
>needed, a coroutine to manage (and filter) all of the command coroutines
>should be created.  Coro::Channel would be used to pass text, objects, etc,
>between coroutines, but ultimately, one coroutine (the command prompt) would
>be reading user input and one or more (the command coroutines or the 
>command-coroutine-manager-coroutine) coroutines would write to the user via
>their socket.
>
>I hope this helps.  
>
>-scott
>
>On  0, "Metz, Bobby W, WCS" <bwmetz at att.com> wrote:
>> Yeh, I was looking at the buffer stuff last night.  Believe expect has a
>> similar "problem"...that's why I canned that script...plus I hate
>> expect. :)
>> 
>> -----Original Message-----
>> From: Andrew Johnson [mailto:aj at exiledplanet.org]
>> Sent: Wednesday, June 29, 2005 7:34 PM
>> To: Metz, Bobby W, WCS
>> Cc: phoenix-pm at pm.org
>> Subject: Re: [Phoenix-pm] Looking for ideas - Perl Telnet Monitor
>> 
>> 
>> On Wed, 2005-06-29 at 19:54 -0500, Metz, Bobby W, WCS wrote:
>> > [snip]
>> > IO, i.e. it looks like regular send/expect stuff to me.  Anyone out
>> > there ever do anything like this or know of some easy Perl trick to
>> > monitor bi-dir IO on a TTY or Net:Telnet session without completing
>> > taking control from the user typing.  I'm sure the solution is staring
>> > me in the face, but right now it eludes me.
>> 
>> bidirectional IO that _doesn't_ take control from the user typing.
>> Well, no.  But you might try IPC::Open2 (I suppose you could capture
>> your prog's STDIN and feed it to the telnet process, and pass back
>> anything that is read from the telnet process's stdout handle).   Check
>> out Chapter 16 (Interprocess Communcation), section 3.3 (Bidirectional
>> Communication) of /Programming Perl/.  Since standard I/O buffering is
>> probably going to "ruin your day" (the Camel's quote), you might also
>> find IO::Select and the IO::Pty (avail on CPAN) module useful.
>> 
>> Hope this helps.
>> 
>> --aj
>> 
>> _______________________________________________
>> Phoenix-pm mailing list
>> Phoenix-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/phoenix-pm
>