Are threads what we really want ???

[Espen Harlinn]

I’ve just spent some time looking through the various RFC’s 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 it’s 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 doesn’t need
the value $i abandon can be used to tell the runtime that we really doesn’t
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 doesn’t wait for foo

        $i->bar(); # since bar is not a oneway the current context waits for bar to
complete it’s 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