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
