RE: Revamping the build system
this is even used for. I think we need some simple way of telling the last step of the build process what's available in terms of external libraries for a given platform/compiler combination. like I might have zlib compiled with M$ VC++ and cygwin, but not with Borland C++ builder. One file for each compiler. It would also be useful to have this kind of info available when building modules later on in the process. Best regards Espen Harlinn
Are threads what we really want ???
Ive just spent some time looking through the various RFCs for Perl 6.
IMHO: The various proposals dealing with multi threading, synchronization
and RPC can be solved in a different way.
Instead of thinking about multiple threads, one could think about multiple
execution contexts. Each instance of an object must belong to one and only
one execution context. Each execution context has an attached security
context and a security manager.
When making a call from an object in one execution context to a method of an
object in another execution context the security context of the caller is
passed to the receiver an validated by its security manager before being
allowed to execute. Asynchronous execution could be implemented using
oneway functions and future variables and a combination of both.
future variables would allow for returning results from oneway
functions, and for turning synchronous functions into oneway functions.
deferred methods would also be very nice. A deferred method is something
that would be executed at some later time when the current execution context
is idle.
If the following keywords were added to Perl:
1. abandon
2. asynch[ronous]
3. at
4. cancel
5. deferred
6. future
7. oneway
We would be able to write code in the following manner:
oneway foo
{
return 1+1;
}
bar
{
return 2+2;
}
future $i = deffered foo();
execution should continue immediately without waiting for foo to execute.
When at a later time we would like to access $i foo would be forced to
execute. If we during further execution decides that we really doesnt need
the value $i abandon can be used to tell the runtime that we really doesnt
want the future $i.
if( something )
{
abandon $i; # abandon the future, foo will still be executed
}
else if(something else)
{
cancel foo; # remove foo from the deffered queue and abandon associated
futures
}
else
{
print($i); # by accessing the future $i foo will be forced to execute
and
# $i will be turned into a normal variable when the
result
# from foo is assigned to it.
}
The at keyword is for executing a method in another execution context
future $i = foo() at somehost.farfaraway.org;
and on the same host
future $i = foo() at ; either as a thread or as a separate process
depending on OS facilities
and for creation of objects in another execution context.
$i = new SomeClass at 'somehost.farfaraway.org' as 'loginid' identified by
'password';
$i-foo(); # since foo is a oneway the current context doesnt wait for foo
$i-bar(); # since bar is not a oneway the current context waits for bar to
complete its exeution
asynch $i-bar(); # explicitly tell the runtime to execute bar as a oneway
deffered $i-bar(); # put the execution of bar() on the deffered queue of
the remote execution context
deffered # anonymous deffered function/block
{
# something to do at a later time
}
asych at # anonymous asynch function/block executed in an dynamically
generated execution context
{
$i-bar(); # get the value of $i from the parent execution
context and
call
# bar at 'somehost.farfaraway.org'
}
try
{
future $i = deffered foo();
# before leaving the try block:
# all futures that has not been abandoned must be satisfied at this
point
# that is $i behaves just like another variable beyond this point
# and deffred functions must be forced to execute
}
catch ...
futures should also be allowed as parameters to functions, so that a future
reference variable could be passed to a function.
I'm well aware that most of this functionality can be achived by other
means - but I think a language and runtime level solution would be most
elegant and portable. My choice of syntax and keywords are for illustration
purposes only.
Best regards
Espen Harlinn
RE: Revamping the build system
Here is just a proposal: 1. Place os neutral code in one directory 2. place os dependant code in platform specific directories 3. create an initial SIMPLE makefile and a config.h for each supported platform/compiler combination I know this isn't hightech, but it works like a charm. 4. write all other build tools in Perl 5. use uuids to identify packages, not name, this way my MY::TextModule and your MY::TextModule can be identified as two different packages, OR require that I do something like harlinn::no::MY::TextModule when I name my packages/modules. 6. And please don't use fork at any time during the build process Ideally only the following tools should be needed during the initial build process: 1. The simplest version of make ever written 2. A modern C/C++ compiler 3. A linker To test for the presence of a particular library and associated include files maintain a list of filenames for each supported platform/compiler combination. Like: ACE: LIB=E:\src\Corba\ACE_wrappers\bin\ace.lib; INCLUDE=E:\src\Corba\ACE_wrappers;E:\src\Corba\ACE_wrappers\TAO TCL: LIB=C:\Tcl\lib\tcl83.lib INCLUDE=C:\Tcl\include DEFINES=WIN32;WINNT=1 // a comment DB2: LIB=C:\SQLLIB\lib\db2api.lib;C:\SQLLIB\lib\db2cli.lib INCLUDE=C:\SQLLIB\include and so on ... or in other words: platform independent package name: LIB=[optional fullpath to library[;optional fullpath to next library]] INCLUDE=[optional fullpath of directory[;optional fullpath to next directory]] DEFINES=NAME1=VALUE1;NAME2=VALUE2 // Comments My point is that the format of this file should be kept really simple and used during the next stage of the build process to generate the final build. If a package is missing from this file, then it's not included in the final build. Best regards Espen Harlinn
RE: new event loop
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 -
