Rocco Caputo wrote:
> ...
> [ *** code *** ]
>
>This could very well be an event driven program, with all the tedious
>mucking about with callbacks done under the hood. Regardless, it could
>run the same as long as either threads OR async I/O are available.
Is this portable enough for Perl? Are there systems (that can run perl5
today) that don't have either threads or async i/o available?
I have another remark about event loops vs. file i/o. I read in a previous
post that the design of the event loops and of the i/o subsystem must
be done as one. THAT'S WRONG! The only thing about file i/o that
matters for the event loop system is whether it will or won't be allowed
to do blocking syscalls. In fact, that's not valid only for the i/o
subsystem,
but to everything that involves blocking the Perl interpreter's process,
like the sleep function.
In the other way around, what matters to the design of the file i/o
subsystem is exactly the same thing: whether it will or won't be using
blocking syscalls. I believe after the decision of whether we will or not
allow blocking (I think most of us go for no blocking..., but see my remark
about portability above), the file i/o subsystem MUST be designed in a
complete modular fashion.
That's actually something I'd like to say about this ``subsystem''-based
design of perl6. For it to be successful, it's imperative that all the
modules
don't know about each other, so that it's possible to replace a subsystem
completely for another that supplies the same interfaces, as it should be
possible to use a subsystem in another program, for example, it should
be possible to use the async i/o subsystem in a C application (through the
low-level interface), linking it directly to the application, without the
necessity to link the whole perl runtime to the application.
At least, that's what I think. What's your opinion?
Branden.
