in reply to timeouts and errors with IO::Select:: and CORE:: select (was Re: Msg.pm extended with "workproc". IO::Select docs)
in thread Msg.pm extended with "workproc". IO::Select docs

Thanks... I obviously got my metaphors mixed. All is well and the quest continues...
Clarification for my enlightenment. The fore part of the statement
my $no_error = my ($r_ready, $w_ready, $e_ready) = IO::Select->select($sel, undef, undef, 2.2);
sets $no_error true if any of the element in the list are defined. And in the case of the TIMEOUT, they will always all be undefined?

It is always better to have seen your target for yourself, rather than depend upon someone else's description.

  • Comment on Re: timeouts and errors with IO::Select:: and CORE:: select (was Re: Msg.pm extended with "workproc". IO::Select docs)
  • Download Code

Replies are listed 'Best First'.
Re^2: timeouts and errors with IO::Select:: and CORE:: select (was Re: Msg.pm extended with "workproc". IO::Select docs)
by ikegami (Patriarch) on Oct 12, 2009 at 17:13 UTC

    IO::Select::select is documented to return an empty list (zero values) on error. It also returns this on timeout.

    And in the case of the TIMEOUT, they will always all be undefined?

    Assigning an empty list to a variable will undefine it, so yes.

    sets $no_error true if any of the element in the list are defined.

    Yes, but not directly. $no_error is set to the number of values returned by IO::Select::select. Since IO::Select::select returns either an empty list or three references, the vars are only undefined when $no_error is false, and they're always undefined when $no_error is false.