>>>>> "UG" == Uri Guttman ([EMAIL PROTECTED]) writes:
UG> it looks pretty powerful which is one reason it may not be good to use
UG> in perl. we don't expect to be doing CORBA level stuff in the core. :)
That wasn't what I had in mind either, but since Perl6 is, as far as I
understand it, going to be a rewrite of most of the perl core I thought
(IMHO) that taking a look at something that has been successfully used in
"real-time" applications to solve the problem at hand could be a good idea.
ACE is also fairly well documented, and there exists a number of tutorials -
among them
http://www.cs.wustl.edu/~schmidt/PDF/ACE-tutorial.pdf
I think the Active Object pattern presented at page 58 might illustrate to
what extent the ACE library can be used to both multiplex, demultiplex and
possibly serialize, marshall and unmarshall events between threads and
possibly processes.
I think that Perl sooner or later will support cross process calls, and the
event dispatching mechanism will at that point have to take this into
account. That is: a call from a process p1 to another process p2 can result
in a call from p2 to p1 before the original call to p2 finally returns to
p1. This only means two things:
- The event dispatching mechanism should be extensible
- The event dispatching mechanism should support recursive calls
This way both CORBA and other RPC mechanisms can be added to Perl6 through
packages in an elegant manner.
Since Perl6 is going to be multithreaded, I think it makes sence to "borrow"
at least some of the design patterns implemented in ACE.
UG> perl6's event loop will need to be tightly integrated with the op
UG> dispatch loop and possibly some other critical subsystems.
IMHO: the ACE_Reactor (in Reactor.h) provides just this kind of
functionality, and it integrates well with just about any event generating
subsystem. The following classes implements various kinds of Reactors:
- ACE_Select_Reactor
- ACE_XtReactor
- ACE_WFMO_Reactor
- ACE_Msg_WFMO_Reactor
ACE_Reactor is an event demultiplexing mechanism, which IMHO illustrates how
the such a mechanism could be implemented in Perl6.
UG> also the memory management scheme we use may not be compatible
UG> with the c++ one in ACE.
One of the neat things about ACE is that you can use just about any memory
management scheme you want to.
UG> ACe doesn't seem to support async file i/o but we can add that on our
UG> own. i think having a common api over all the different async file i/o
UG> api's will be very popular. we can do this in the perl5 event module.
ACE does support async file io through the descendants of classes found in
Asynch_IO_Impl.h and Proactor.h. This currently (to my knowledge) only works
on Win32 platforms and on platforms supporting POSIX aio calls.
Best regards
Espen Harlinn
Senior Engineer, Software
Seamos AS
---------------------------------
mailto: [EMAIL PROTECTED]
Phone: +47 55 22 07 81
Fax: +47 85 02 29 43
Address:
Stokkedalslia 5
5155 BØNES
NORWAY
---------------------------------
