On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> 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?
Acorn's RISC OS has no threads, and file I/O blocks.
(you don't even get non-blocking I/O)
And it runs 5.005_03 just fine.
> 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.
This seems a very sensible idea to design in.
I'd agree with "whole" - if it transpires that it's best for perl to use
SVs (or their new equivalent) as buffers for the IO system rather than
plain pointers and lengths, then I'd consider it sensible to consider this
design goal met if async i/o subsystem has a dependency on the scalar buffer
subsystem (or at least one part of it, as SVs in turn might make requirements
on memory allocation APIs). That's still not the whole perl runtime though.
Nicholas Clark
