Re: How to use select (select(2)) in Perl?

From: Bernie Cosell (bernie_at_fantasyfarm.com)
Date: 01/28/04 

Date: Wed, 28 Jan 2004 08:23:15 -0500

Ben Morrow <usenet@morrow.me.uk> wrote:

}
} Bernie Cosell <bernie@fantasyfarm.com> wrote:

} > [and it still leaves me a bit mystified
} > as to WHY the simple global-assignment doesn't work, but the
} > global-assignment *across* a package does. that means that somehow when
} > you do "$pack::var" perl does something a tiny bit different if you're *in*
} > package 'pack' or in some other package... Odd...:o)]
}
} Think about it. Use strict has to shout at you about using a global
} unless
}
} 1. you have declared it with our,
} 2. it is fully qualified, or
} 3. it has been exported by some module.

Would you care to say where you got these three rules from? I got this
from MY version of the online perl docs:

   (F) You've said "use strict vars", which indicates
           that all variables must either be lexically scoped
           (using "my"), declared beforehand using "our", or
           explicitly qualified to say which package the global
           variable is in (using "::").

I didn't see anything that lead to inferring your tidy-three rules. There
was a mention that I found a bit cryptic [even knowing what it was supposed
to mean]:

         (F) While "use strict" in effect, you referred to a
           global variable that you apparently thought was
           imported from another module, because something else
           of the same name (usually a subroutine) is exported by
           that module. It usually means you put the wrong funny
           character on the front of your variable.

Perhaps we could agree that the ONLY real change in the documentation
that'd finesse this tempest in a teacup would be to add your third rule to
the first bit of documentation... something like

           declared beforehand using "our",
           explicitly qualified to say which package the global
           variable is in (using "::"), or exported into the current
           package from some other package.

If there's no disagreement about the above [and it is actually correct],
I'll be happy to put that tiny change into perldiag. [although I don't
think I'm a 'registered' guy so I'd have to find out how to go about doing
that...]

} > Well, sounds like it on two fronts:
} >
} > 1) you're apparently an advocate that there should only be ONE way to do
} > things. IO::File is there, and the direct use of 'open' is now, in your
} > world, deprecated. [oh, sorry, you were just making the parallel arg about
} > IO:Select and select()..:o)]
}
} There is an important difference between IO::Select and IO::File,
} which is that IO::Select actually does something useful. As you found
} out, doing a low-level select call yourself is fiddly and requires
} some rather cryptic and unintuitive, not to mention C-like, operations
} to construct the arguments and get the data back out.

Speak for yourself at how fiddly an "unintuitive" it is. And you think the
rules for ">" "+>" "&" "|" etc aren't 'fiddly' and C/unix-like with open?
The difference is only that you don't understand 'select()' and aren't
comfortable with the vec stuff, and perhaps others are [you run into
similar things with using raw sockets and messing with "packed" IP
addresses -- some programmers can't stand dealing with the machinery, other
prefer to have to flexibility to use it directly]

} ... IO::Select is a
} very thin wraper around that, that provides a Perlish interface.

No, not "perlish" but "perl object-oriented". And not so paper thin -- it
pulls in more of the IO:: machinery [IO::Handle, at the least]. Not a huge
amount of stuff, I meant "relatively" behemoth, because you have the [at
least two] packages you don't otherwise need, and the OO overhead on all
the operations, compared with, well, just doing "select()".

} ... I'd
} be willing to bet that if perl hadn't had select in the first place,
} and IO::Select where to be implemented now as an extension, the
} interface would be much as it is now; perhaps with a note in the
} documentation saying 'the underlying select(2) call is available as
} IO::Select::sysselect'.

I don't know: is there *ANY* other facility in Perl that is *ONLY*
available through an OO interface??

} IO::File, OTOH, gives you nothing over a simple open: indeed, I find
}
} my $fh = IO::File->new("< file");
}
} substantially harder to read than
}
} open my $FH, "< file";

Again, your bias that you'd impose on us all, I guess? You seem to have
that bias on your feeling about using select().

} > It is one thing to carp about $^H, which is clearly documented:
} >
} > $^H WARNING: This variable is strictly for internal
} > use only. Its availability, behavior, and con­
} > tents are subject to change without notice.
} >
} > but in IO::Select, it just says:
} >
} > The "IO::Select" package implements an object approach to
} > the system "select" function call.
} >
} > Which hardly sounds like "THIS IS THE ONLY APPROVED WAY TO DO SELECT IN
} > PERL", does it?
}
} No. What I was suggesting was that, since the documentation for select
} is (apparently) cryptic and inadequate to enable anyone without
} intimate knowledge of perl internals to use it, it be changed to say
} something more along those lines. Then perhaps we wouldn't get muppets
} here asking questions whose answers require nothing more than a small
} amount of thought.

And we disagree -- I think that if anything, someone who cares *should*
make the available docs useable [even if it is only with comments in
IO::Select!]. I do believe that what the current docs *say* for IO::Select
is the proper philosophical path: that it is not the one-true-way to
achieve selectness, but provides an *OO* approach for those who prefer it.

  /Bernie\ 

-- 
Bernie Cosell                     Fantasy Farm Fibers
bernie@fantasyfarm.com            Pearisburg, VA
    -->  Too many people, too few sheep  <--

Relevant Pages