[pypy-dev] Continuations and sandboxing

[Maciej Fijalkowski]

Hello.

This discussion have drifted considerably. In general this is the pypy
development mailing list, so personally I would like to keep
discussions only to things that are either very interesting for people
actively working on PyPy or have remote possibility that someone will
start working on them. Discussing STM without someone being interested
in actually looking is out of topic.

PS. Feel free to correct me if anyone working actively on pypy is
finding this discussion useful for PyPy development.

Cheers,
fijal

On Tue, Jan 11, 2011 at 9:43 AM, William ML Leslie
<william.leslie.ttg at gmail.com> wrote:
> On 11 January 2011 15:25, Nathanael D. Jones <nathanael.jones at 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
> locking?
>
>> On Mon, Jan 10, 2011 at 5:05 PM, William ML Leslie
>> <william.leslie.ttg at gmail.com> wrote:
>>>
>>> On 11 January 2011 07:18, Paolo Giarrusso <p.giarrusso at 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
> coarse.
>
> 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
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>