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.
We could add a few keywords and call the language variant Perlang, too!
Anyway, there *is* a threefold plan, involving quotas, privileges/capabilities, and restricted embedding environments.
clock time (ulimit style)
This'd be a per-interpreter, per-user quota.
disk (ulimit style)
This'd be done probably by the embedding environment. (Though actual IO operations would be subject to quotas)
memory (ulimit style)
Quotas.
namespace access
Privileges
PMC (user-level functions, variables (e.g., %ENV, etc.)
Also privileges.
individual builtins (looping, 'my', assignment, etc.)
Privs, possibly quotas and the embedding environment for IO and event type things.
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?
Mainly because it's a bit too restrictive.
What I'm planning on is a VMS-style quota, privilege, and identifier system. (Or, rather, an extendable privilege system where extra privs can be defined and set/reset) Nothing too fancy, but expressive enough to allow for reasonable control over restricted interpreters.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
