Hi,
Am 12.11.2010 02:47, schrieb Ben Goldberg:
I would like to know, is perl6 going to have something like select
(with arguments created by fileno/vec), or something like IO::Select
(with which the user doesn't need to know about the implementation,
which happens to be done with fileno/vec/select), or only an event
loop.
The IO specification for Perl 6 is very suboptimal as is. On the one
hand it's over-engineered, in that there's a plenthora of confusing
roles that makes it hard to do anytyhing. On the other hand it's
under-engineered in the sense that it doesn't even talk about
non-blocking IO yet.
If that's a topic you know and care about, I'd welcome any contributions
you can make to the spec. Don't be scared, it's just a collection of
text documents :-)
So if you send me your github ID (get one if you don't have one), I'll
give you commit access.
I would recommend that there NOT be any sort of fileno exposed to the
user, unless he goes out of the way to get it -- any function (in
particular, posix functions) should simply take a perl filehandle, and
that function in turn would pull out the fileno (or fail
appropriately, if the filehandle doesn't have a fileno). If users
want to know if filehandles correspond to the same underlying file,
then there could be a method -- perhaps $fh.uses_same_desciptor($fh2),
or somesuch.
Agreed. A higher level interface than POSIX would be a good default, IMHO.
If there's a select() builtin (and I'd much rather that there not be
-- it should be hidden away in a class, like perl5's IO::Select), I'd
very much hope that it would take and return Sets of filehandles, not
vec packed strings. I'd prefer there not be one[**]
As I tried to imply above, you can shape Perl 6 if you want. If you
supply a superior alternative to select/IO::Select, people will happily
implement and use it.
Lastly, if perl6 has an efficient enough built-in event loop, and
sufficiently lightweight coroutines (or maybe I should say fibers?),
then we might not need to have any kind of explicit multiplexing.
I'm not sure if the question about having an event loop is fully
answered; there was some discussion about it in relation to concurrency
and feed operators, but I didn't follow them too closely.
We certainly have coroutines in the form of gather/take.
I'm sorry for not commenting more on your actual proposals, which is
mostly due to my lack of real-world experience with non-blocking IO.
Cheers,
Moritz
