On Mon, Feb 02, 2009 at 11:00:28AM -0300, Daniel Ruoso wrote: : Em Seg, 2009-02-02 às 13:51 +0100, Leon Timmermans escreveu: : > On Mon, Feb 2, 2009 at 1:05 PM, <pugs-comm...@feather.perl6.nl> wrote: : > > -the latter case C<$!> is set). : > > +the latter case C<$!> is set). The C<:async> flag lets the call : > > +return an undefined value if no character is immediately available. : > IMHO it would be better to call that non-blocking IO instead of : > asynchronous IO, but I'm POSIX-biased. : : Agreed, it would be async if that was a request for a character that : would be replied using some other call, in that case it is non-blocking : read.
Yes, to me async implies setting up push semantics to some kind of an event handler, if only a specialized one for a particular event. Non-blocking pull semantics tend to result in polling loops, which are problematic. With its lazy lists Perl 6 is optimized more for push semantics and feeds, but this option invites polling, so maybe it should be called :poll to be clear about that, if we have it at all. : But I should argue that it should be a property of the IO object, not of : every individual method call.. Indeed, though there are interfaces that want to go back and forth, so it's necessary that the IO object's blocking property be mutable, if we want to avoid adding the option to individual calls. It's also not clear how this should interact with buffering systems like stdio. But in any case, speaking directly to the IO stack is likelier to give consistent results than playing mix-n-match with various calls on the IO stack that make various assumptions. All of which has to be balanced off against user convenience, and most naïve users would just like a call that says gimme a keystroke. Which is not what getc was originally intended for, in any case, since it lives on top of stdio and usually just means take the next character from the input buffer. Larry
