The summary: request for architectural analysis.
The motivation: there are certain languages, possibly including perl 6,
that will benefit from the ability to flow from one parrot interpreter
to another. For example:
#!//googlestorage/programs/perl7.08032005
use remote qw( :googlecompute-shared :ibmgrid1 compute.delictis.com );
sub remote_num_of_users {
on remote { use local settings; return $hostname, $current_users };
}
my $values = remote_num_of_users;
foreach my $i (keys %{ $values }) {
print join ('\t', ($i, values->{$i}, "\n"));
}
felix-ipod1 $ ./remote_users.pl
googlecompute1.google.com 588345
googlecompute2.google.com 249382
googlecompute3.google.com 291991
googlecompute4.google.com 188126
googlecompute5.google.com 328340
googlecompute6.google.com 49392
ibm-compute-public1.grid.ibm.com 38289
ibm-compute-public2.grid.ibm.com 39482
ibm-compute-public3.grid.ibm.com 6004
ibm-compute-public4.grid.ibm.com 493
compute.delictis.com 2
Trivial enough. However, for security reasons permissioning has
to exist at the bytecode/interpreter level, because you may wish
to assign per-user permissions on the following axes:
cpu time (ulimit style)
clock time (ulimit style)
disk (ulimit style)
memory (ulimit style)
namespace access
PMC (user-level functions, variables (e.g., %ENV, etc.)
individual builtins (looping, 'my', assignment, etc.)
Is anyone aware of any reason why the straightforward approach --
implementing a per-thread 'running restricted' flag, an extra if
branch in the bytecode interpreter code paths, a bytecode to
flip into restricted mode*, and a per-PMC permission 3-bit (rwx)
permission bitmask -- would not be the best solution?
Are there any early concerns or optimizations anyone can envisage?
Thanks --
Felix
