On Mon, 30 Nov 2009 04:06:36 +0100 Aristotle Pagaltzis <pagalt...@gmx.de> wrote:
> Seems to me that it is the job of IO::Foo classes to respond to > a `select` as being ready to read from, if they have buffered > data, even if the underlying handle is not. > > I don’t know if that response is overridable in Perl classes. Even if IO::Select might be overrideable, I'd doubt that select() is, or poll(), or ppoll(), or epoll_pwait(), or... any of the other O(1) OS-specific blocking prims. Instead I suggest some sort of pure-perl toplevel method. The way I usually write easy sync-or-async IO classes is to give the filehandle-like object its own internal buffer, and have two APIs into it: get_foo - just read buffer or return undef wait_foo - try to read buffer, or synchronously block on IO A supplimentary method, advise_readable, informs the object that a sysread() operation may be performed; when called it does a sysread() into its own internal buffer. Then the get_foo can be written simply as sub wait_foo { my $self = shift; while(1) { my $foo = $self->get_foo; return $foo if defined $foo; $self->advise_readable; # will block on blocking sockets } } Synchronous programs can just call the wait_foo method to block and get new foos; asynchronous programs can call advise_readable every time the underlying blocking prim says it's a good idea, then repeatedly call get_foo to drain the buffer. For example, see the split APIs provided by http://search.cpan.org/~pevans/Term-TermKey-0.04/ (at the perl level) http://home.leonerd.org.uk/code/libtermkey/ (at the C level) -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: PGP signature