On Sat, 2004-08-28 at 06:01, Matt Sergeant wrote:
> As an addition to this thread, I just wanted to add that having each
> DBD implement their own event loop (via select() or otherwise) is not
> acceptable. Anyone who has done event driven programming will
> understand the mantra: There can be only one. Only one event loop that
> is. If you implement an event loop in your DBD then you BLOCK my event
> loop, which I cannot allow to happen. I don't believe that perl threads
> are stable/fast enough to fix this problem in a very large scale
> program.
>
> The API *has* to be something that can integrate with other event
> loops. My suggestion for the only thing scalable enough for this is a
> file descriptor which can be notified of readiness.
>
> Matt.
Supporting deferred-asynchronous mode with a ready()
method that polls and returns either immediately or after handling
availble data would not block your event loop.
An event loop inside one's DBD would be appropriate for a fully
asynchronous mode, however you choose build that.
Based on this comment I would like to extend the proposed extension
to include an optional $h->fileno() method, which would return
an arrayref containing file descriptor numbers for use in the main
event loop, so a busy event-driven system will know when it can be sure
that calling $h->ready() will not waste cycles.
{
my $htmp = $h;
my $coderef = sub { $htmp->ready and push @Readies, $htmp };
$Callback[$_] = $coderef for @{$h->fileno};
}
...
buildselectvectors(@Listeners,@Clients,@Callbacks);
select ...
An array ref rather than one number, so handles that have multiple
connections open can report them all.
