Front page | perl.perl6.internals |
Postings from January 2001
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.Thread Previous | Thread Next