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

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.


Reply via email to