in reply to Flaky Server (IO::Socket and IO::Select Question)

First, congratulations on using Perl as it was meant to be used: in embedded systems, not in an unpleasant CGI script <g>

Second, it's not clear to me what you mean about your difficulty using select:

I thought of using a timeout on the can_read(timeout) call but the STDIN (actually redirected through TCPSERVER from the operator interface device) will reset that value when it wants more action.

You should be able to use select on both your TCP connection and STDIN; when you come out of select, zero or more file handles will be ready to read (or write, or will have exceptions on them, depending on what you were looking for). If zero, you had a timeout.

You may want to look into the Event or POE CPAN modules, both of which allow for simple creation of event-driven systems that can use select as well as timer events.

  • Comment on Re: Flaky Server (IO::Socket and IO::Select Question)

Replies are listed 'Best First'.
Re: Re: Flaky Server (IO::Socket and IO::Select Question)
by ginseng (Pilgrim) on Jun 13, 2001 at 01:37 UTC

    Yes, yes, and I just got my new license plate today: CTL GEEK. I'm happy.

    My difficulty with the select->can_read() statement is with it's appropriateness for my task, and not with the IO::Select code at all. It returns at the end of timeout to tell you nothing came from any handle, as designed. I need something that will tell me, "You told me to listen to this handle, but the handle went away and you'd better do something about that."

    For my main purpose, monitoring the operator interface on one socket (though treated as STDIN) and the motion controller on the other, it does exactly as specified.

    But again, what I really need is to know how get IO::Socket or IO::Select to tell me that a socket went away.

    ginseng