On Mon, 8 Jan 2001 23:12:15 -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?
I've since coded phat, a simple C prototype of the I/O and interpreter
subsystems. See: <http://poe.perl.org/phat/phat.c>; it compiles in the
usual way. I hope people can poke at it, perhaps turning its design
into something useful for Perl 6. The implementation is very bad in
many ways, but it's just a model.
Phat's I/O can fall back to (or be replaced with) blocking calls on
systems where async I/O isn't available. The opcode interpreter and main
loop don't need to know about the replacement. I need to add some file
I/O to its tiny AIO subsystem to show how this works because sleep is a
bad example (I explain why later in this message).
Unfortunately, blocking I/O will kill concurrency. This isn't a
problem for single-threaded programs that don't use events or
callbacks at the language level. That covers most Perl 5.x programs,
and it especially covers the ones which were originally written to run
in these limited environments.
The real problems crop up when newer programs try to use those
language constructs in an environment that doesn't support any form of
concurrency. These programs will run poorly if they use blocking I/O.
They may even deadlock. Ones that are lucky or carefully designed,
though, can still use atom-timesliced threads.
I've addressed this problem in poe2, an experimental multithreaded
dispatcher I wrote in Perl. It exports a flag indicating a lack of
true concurrency. Programs can use it to adapt to the single-threaded
environment or just croak if they won't run there.
>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.
Sleep's a bad example because it can be implemented as a busy loop
where there's no other choice. Here's sleep as an opcode loop.
sleep:
push time
push_sv_iv wake_time
jump_if_less_than sleep
return
This would hog CPU, but it would run this way mainly on systems where
busy loops are de rigueur.
The jump back to C<sleep> ends a timeslice in phat, returning control
to the main loop. In this case, even the most concurrency-challenged
systems can do asynchronous delays in their sleep.
Operating systems that require CPU hogging busy loops yet
paradoxically don't welcome them usually have syscalls to yield time
back to the OS. DOS programs are notorious for using busy loops
wherever they need to multitask. DOS includes an INT 21h "syscall"
that will yield system timeslices back to Windows or OS/2, if the
program happens to be running in one of them. I would be surprised if
Linux and other systems' DOS emulation didn't also handle it.
Phat's aio_dispatch_events() is also where it checks for events. This
function is virtually useless in a blocking I/O library, since the
requests for callbacks will block until I/O is done. The main loop,
however, can continue calling it to yield back time to the operating
system where it's necessary.
Re: Writing the subsystems together.
I think you misunderstand the other message's intent. The main loop,
the interpreter, and I/O, are three separate subsystems. I think
everyone agrees with you that they should be interchangeable, but
their public interfaces are sufficiently intertwined that they should
be designed, at least at their borders, as a complete system.
>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.
I think this is where vtables come in. If perl itself were to use
them, each subsystem could plug itself in at link time. It may even
be possible to defer subsystem plug-ins until their language-level
interfaces are used.
I've also experimented with plug-in subsystems at the Perl module
level in the poe2 project. Its resource management scheme might be
a useful springboard for pluggable Perl subsystems. poe2's resource
manager is at <http://poe.perl.org/poe2/POE.pm>. The rest of the
project is in the same directory, including current tarball of the
entire tree.
>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?
If you mean that subsystems need to understand each others' public
interfaces and nothing more, then I agree. Otherwise, how would one
subsystem call another if it didn't know what to call?
Subsystems should stand alone wherever possible, but I think isolating
them from Perl data types would make little sense. Why create a great
data manipulation library only to rewrite it in every subsystem?
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
