[racket-dev] [plt] Push #27825: master branch updated

From: Jay McCarthy (jay at racket-lang.org)
Date: Tue Nov 26 11:49:09 EST 2013

I agree that it is different.

I disagree that this is a problem.

The documentation says that is executes the code with a time
restriction. This implies to me that (call-with-limits X #f t) should
not use more than X secs of resources, but it is trivial to produce
counter-examples. Without this change, call-with-limits is totally
useless for limiting the time taken by untrustworthy code.

The fact that there was no test case that failed with my change tells
me that the code was not written to make one decision or another. I
charitably assume that this was because the good (current) behavior is
what was wanted but the variety of attacks on it were not thought of.

Nevertheless, if you and Matthew think this is a bad change, we should
change everywhere in racket/sandbox that mentions time restrictions to
clarify that they don't actually restrict time of the code.


On Mon, Nov 25, 2013 at 3:02 AM, Eli Barzilay <eli at barzilay.org> wrote:
> IIUC, this makes the limit thing -- and therefore sandboxes -- behave
> *very* differently.  The original intention was that the time limit is
> on something similar to what you get with `time'.
> A very visible way to see the effect of this change:
>     -> ,r racket/sandbox
>     -> (define e (make-evaluator 'racket))
>     -> (e '(define foo 1))
>     -> (e '(thread (lambda () (sleep 5) (set! foo 2))))
>     #<thread>
> This used to happen immediately, with the thread continuing to run
> inside the sandbox.  After your change, the last line hangs until the
> thread is done.  Using a bigger sleeping time will make it throw an
> error when it previously didn't.  Similarly,
>     (make-module-evaluator "#lang racket (thread (λ() (sleep 99)))")
> used to work and will throw an error now, and of course, any code that
> runs some kind of sandboxed server will probably break now.
> I think that instead of this, it'd be better to write a helper that
> runs a thunk and waits for it and for any generated threads to end,
> and suggest using this helper when you want to wait for all threads in
> a `with-limits'.  (It might also be useful in the profiler, where a
> similar kind of wait-for-all is done.)
> On Friday, jay at racket-lang.org wrote:
>> jay has updated `master' from e0026f5de4 to 79f8636e1e.
>>   http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e
>> =====[ One Commit ]=====================================================
>> Directory summary:
>>   52.6% pkgs/racket-pkgs/racket-test/tests/racket/
>>   45.6% pkgs/sandbox-lib/racket/
>> ~~~~~~~~~~
>> 79f8636 Jay McCarthy <jay at racket-lang.org> 2013-11-22 14:25
>> :
>> | Ensure that threads created within call-with-limits are accounted
>> | during the time/space limits
>> :
>>   A pkgs/racket-pkgs/racket-test/tests/racket/sandbox.rkt
>>   M pkgs/sandbox-lib/racket/sandbox.rkt               | 81 ++++++++++++++------
>>   M .../racket-test/tests/racket/sandbox.rktl         | 48 ++++++++----
>>   M .../scribblings/reference/sandbox.scrbl           |  4 +
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.