Nicholas Clark wrote:
>Branden wrote:
>> 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.
I've thought about this for some while now and have some ideas about modular
design I'd like to expose. Sorry if I'm saying something silly inside here,
I'm not at all an expert on Perl's guts, but I think starting a thread on
modular design is a very important thing now, as we are restarting from
scratch.
I believe perl6 should be designed in layers. Each layer knows the interface
of the layer that is below it and exposes its interface to the layer above
it. The lowest level layer is what I will call the kernel. Above the kernel
are the subsystems, and above them are the extensions.
What the kernel contains:
1) Structs that are the base for data structures, a la RFC 35.
2) Actual data structures for base types, i.e., scalars, arrays & hashes.
3) Threads. (???)
4) As it seems, event loops.
Notes about it:
1) Actual data structures for scalars, etc. don't actually need to be in the
kernel if we have the structs that are the base for data structures.
However, as many of the subsystems are expected to work directly with base
types, it's better to accomodate them here. I'd also think it's awkward to
re-use one of perl's subsystem in another application without using it's
base types.
2) The interpreter isn't in the kernel. I guess that's strange, but, I think
we could have the op interpreter as a subsystem, and have the kernel only
expose a interface based on callbacks for the event loop. The op interpreter
subsystem would hook itself to the kernel, setting the callbacks to its
functions.
3) As the discussion goes on if perl IS or ISN'T an event loop, I don't know
if its base is or isn't the event loop, I am only guessing here...
4) As I said, I'm not an Perl guts expert at all!!! I need your opinions on
this so we really do the right thing.
The next layer would be built by the subsystems. I've asked myself sometime
ago: what is a subsystem? I guess it's a modular piece of code that depends
only on the kernel (and possibly on other subsystems). Than I had the idea
of re-using some subsystem (the async i/o and regex would be nice to do
this...) in other applications.
I can see 3 subsystems so long: the async i/o, the regexp and the (now
introduced by taking it off the kernel) op interpreter subsystem. I'm sure
there are more, althought. For example, signals could be handled by some
subsystem as well, with hooks into the kernel again.
On top of this, in the next layer, would be the extensions. These would use
the base data structures in the kernel (SV, AV, ...) as well as things in
the subsystems layer (what now is PerlIO, will be AIO; Regexp engine should
be exposed with an interface; perl_call_* will be probably in the op
interpreter subsystem; and so on...). Here goes what will replace XS.
Possibly a XS version will go here too, to accomplish still using old
XS-based extensions.
I think I should address the efficiency subject now, because I'm almost sure
someone will say ``layers are very inefficient...'' and such things. I have
to say I usually think ```layers suck'', that's why I like Perl so much, it
lets us approach our problems directly, without knowing the gory details of
various sucking middleware between applications and databases and such.
But, back to the efficiency issue, I _THINK_ the scenario I described is not
inefficient. What it does differently from a monolithic system: it uses
callbacks instead of fixed function calls, and it doesn't inline the
functions. First, Callbacks take at most 1 cycle more than fixed function
calls (is this right???), because the processor must fetch the code address
from an address of memory, instead of just branching to a fixed memory
address. Comparing to all the code Perl uses to handle SVs and such stuff, I
think 1 cycle wouldn't kill us at all!
Well, inline functions _CAN_ make a difference if there are many calls to
one function inside a loop, or something like this. And this _CAN_ be a
bottleneck. Well, I have one idea that keeps our design modular, breaks
dependencies between subsystems (like that of using async i/o system without
having to link to the whole thing), and achieves efficiency through inline
functions. We could develop a tool that works in the source code level and
does the inlining of functions for us. I mean a perl program that opens the
C/C++ source of the kernel, looks for pre-defined functions that should be
inlined, and outputs processed C/C++ in ``spaghetti-style'', very messy,
very human-unreadable, and very efficient.
I believe that's it for now. Comments, please???
Branden
_________________________________________________________
Oi! Você quer um iG-mail gratuito?
Então clique aqui: http://www.ig.com.br/paginas/assineigmail.html
