On 11 January 2011 15:25, Nathanael D. Jones <nathanael.jo...@gmail.com> wrote:
> Regardng #1: Sandboxing is a major concern for me. Different code will need
> different sandboxing levels depending upon who created/approved the code.
> I can't have everything in one sandbox - I need isolated boxes on a
> per-request level.

You will probably want to implement a capability architecture, where
the authority to perform some action is bundled together with the
method that invokes it.  The language E ( http://erights.org ) was
designed for this sort of thing (I think it was written for a MUD
originally), and would be worth looking at even if you didn't use the
language itself.  Capability theory is sadly not well known,
considering just how well it solves ever more common problems.

> The idea is that if functions return the next function to call instead of
> calling them, we have explicit tail-call elimination, and we have an
> explicit point at which we can rebuild the sandbox and upgrade the code.

Right, this is the "driver loop" implementation of TCE.  There are
several implementations of TCE kicking around, (including one I did
for cpython some time ago, a decorator that would patch load ... call*
... return bytecodes with a call to a class that collects the function
and arguments, and wraps the function in a driver loop that is
bypassed when the target is marked as recursive, too).

Unfortunately, using only implicit continuations, once you enter
somebody's function, you have no way to get out of it - that person
can except: and trap you there if they like.  E has a way to protect
against this, but you can't protect against the function busy-looping
without something more (a way to kill threads, specifically, which
probably means taking down the process).

> Much data will be user scoped, and therefore lockable.

What does lockable mean in this case?

Under what conditions does reloading happen while a user continuation
is in play?  How do you want continuations to interact with the

> On Mon, Jan 10, 2011 at 5:05 PM, William ML Leslie
> <william.leslie....@gmail.com> wrote:
>> On 11 January 2011 07:18, Paolo Giarrusso <p.giarru...@gmail.com> wrote:
>> >> The one issue that interests me is where you implement the persistence
>> >> boundary - do you go with orthogonal persistence and act as if
>> >> everything is preserved, or assume all user code is run within some
>> >> sort of (fast and loose) transaction that can be re-entered at will,
>> >> providing an API for persistent data access?  The second case makes
>> >> the reloading question a bit more reasonable, because you can always
>> >> throw away the current delta and replay the external effects, assuming
>> >> the interface for the external events hasn't changed significantly.
>> >
>> > The key question is: when would you start and commit such transactions?
>> >
>> > Apart from that, your idea looks very similar to Software
>> > Transactional Memory (STM). STM restarts explicitly-marked
>> > transactions in a thread when some other thread modifies the affected
>> > data (which would be a data race) and commits its transaction. In your
>> > case, a transaction is restarted when some other thread modifies the
>> > involved code.

I don't think it would be useful at all to have regular STM
transactions delimited at the room boundary - there are surely going
to be other people interacting with the room at the same time as you,
and sending everyone else back to the start of the room every time
someone modifies the room is going to get old very quickly.  The
boundary introduced by modifying code is probably significantly more

If you are storing (as the transaction log) only the external effects
(user input, random.* output), however, you can build effect
commutators automatically.  For example, given a code change to object
X, you can initialise it with the previous persistent state, and
replay the effects within the current transaction.

That said, I think having a transaction per room is too coarse - per
input or set of inputs makes even more sense.  The idea there is that
there is much less code to replay when two effects interfere.

William Leslie

Reply via email to