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 <j...@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 <e...@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, j...@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 <j...@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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
