<div dir="ltr">I think that, in this case, changing the documentation and adding the functionality with a different name is the way to go.<div> </div><div>Robby</div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy <<a href="mailto:jay@racket-lang.org" target="_blank">jay@racket-lang.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <div class="HOEnZb"><div class="h5"> On Mon, Nov 25, 2013 at 3:02 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> 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, <a href="mailto:jay@racket-lang.org">jay@racket-lang.org</a> wrote: >> jay has updated `master' from e0026f5de4 to 79f8636e1e. >> <a href="http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e" target="_blank">http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e</a> >> >> =====[ One Commit ]===================================================== >> Directory summary: >> 52.6% pkgs/racket-pkgs/racket-test/tests/racket/ >> 45.6% pkgs/sandbox-lib/racket/ >> >> ~~~~~~~~~~ >> >> 79f8636 Jay McCarthy <<a href="mailto:jay@racket-lang.org">jay@racket-lang.org</a>> 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: > <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life! _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </div></div></blockquote></div> </div>