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

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue Nov 26 11:54:06 EST 2013

I think that, in this case, changing the documentation and adding the
functionality with a different name is the way to go.

Robby



On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy <jay at racket-lang.org> wrote:

> 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.
>
> Jay
>
>
>
> 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!
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20131126/0a4ca35b/attachment-0001.html>

Posted on the dev mailing list.