<div dir="ltr"><div>This isn't the semantics of the limits. It is about the way that calling the evaluator interacts with threads. Changing this program (from Eli's email)</div><div><br></div><div><span style="font-family:monospace">    -> ,r racket/sandbox</span><br style="font-family:monospace">
<span style="font-family:monospace">    -> (define e (make-evaluator 'racket))</span><br style="font-family:monospace"><span style="font-family:monospace">    -> (e '(define foo 1))</span><br style="font-family:monospace">
<span style="font-family:monospace">    -> (e '(thread (lambda () (sleep 5) (set! foo 2))))</span><br></div><div><br></div><div>so that that final call doesn't return until the thread terminates is a huge change of the semantics and not at all what a reasonable reading of the docs would suggest. The docs for make-evaluator don't specifically mention 'thread' but it seems pretty clear to me that when you pass a program that creates a thread to an evaluator, the call returns without waiting for the thread to terminate.</div>
<div><br></div><div>I also agree with Eli that this would break essentially all uses of threads in sandboxes.</div><div><br></div><div>Robby</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Nov 26, 2013 at 10:57 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay@racket-lang.org" target="_blank">jay@racket-lang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How can you change the documentation to say anything other than<br>
"Wherever you see an thunk having a time restriction, don't think that<br>
that means the thunk is restricted to using only a certain amount of<br>
time"? We'd have to say something like "Time in this content is a<br>
-first-order- notion of time, despite being in Racket where we<br>
generally try to go out of our way to make sure everything works in<br>
every higher order context." My position is that racket/sandbox has<br>
always been broken and that any reasonable reader of the documentation<br>
would have expected this behavior all along. (In fact, both Matthew<br>
and I did think it did this and were surprised that it didn't.)<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Nov 26, 2013 at 9:54 AM, Robby Findler<br>
<<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote:<br>
> I think that, in this case, changing the documentation and adding the<br>
> functionality with a different name is the way to go.<br>
><br>
> Robby<br>
><br>
><br>
><br>
> On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy <<a href="mailto:jay@racket-lang.org">jay@racket-lang.org</a>> wrote:<br>
>><br>
>> I agree that it is different.<br>
>><br>
>> I disagree that this is a problem.<br>
>><br>
>> The documentation says that is executes the code with a time<br>
>> restriction. This implies to me that (call-with-limits X #f t) should<br>
>> not use more than X secs of resources, but it is trivial to produce<br>
>> counter-examples. Without this change, call-with-limits is totally<br>
>> useless for limiting the time taken by untrustworthy code.<br>
>><br>
>> The fact that there was no test case that failed with my change tells<br>
>> me that the code was not written to make one decision or another. I<br>
>> charitably assume that this was because the good (current) behavior is<br>
>> what was wanted but the variety of attacks on it were not thought of.<br>
>><br>
>> Nevertheless, if you and Matthew think this is a bad change, we should<br>
>> change everywhere in racket/sandbox that mentions time restrictions to<br>
>> clarify that they don't actually restrict time of the code.<br>
>><br>
>> Jay<br>
>><br>
>><br>
>><br>
>> On Mon, Nov 25, 2013 at 3:02 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
>> > IIUC, this makes the limit thing -- and therefore sandboxes -- behave<br>
>> > *very* differently.  The original intention was that the time limit is<br>
>> > on something similar to what you get with `time'.<br>
>> ><br>
>> > A very visible way to see the effect of this change:<br>
>> ><br>
>> >     -> ,r racket/sandbox<br>
>> >     -> (define e (make-evaluator 'racket))<br>
>> >     -> (e '(define foo 1))<br>
>> >     -> (e '(thread (lambda () (sleep 5) (set! foo 2))))<br>
>> >     #<thread><br>
>> ><br>
>> > This used to happen immediately, with the thread continuing to run<br>
>> > inside the sandbox.  After your change, the last line hangs until the<br>
>> > thread is done.  Using a bigger sleeping time will make it throw an<br>
>> > error when it previously didn't.  Similarly,<br>
>> ><br>
>> >     (make-module-evaluator "#lang racket (thread (λ() (sleep 99)))")<br>
>> ><br>
>> > used to work and will throw an error now, and of course, any code that<br>
>> > runs some kind of sandboxed server will probably break now.<br>
>> ><br>
>> > I think that instead of this, it'd be better to write a helper that<br>
>> > runs a thunk and waits for it and for any generated threads to end,<br>
>> > and suggest using this helper when you want to wait for all threads in<br>
>> > a `with-limits'.  (It might also be useful in the profiler, where a<br>
>> > similar kind of wait-for-all is done.)<br>
>> ><br>
>> ><br>
>> > On Friday, <a href="mailto:jay@racket-lang.org">jay@racket-lang.org</a> wrote:<br>
>> >> jay has updated `master' from e0026f5de4 to 79f8636e1e.<br>
>> >>   <a href="http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e" target="_blank">http://git.racket-lang.org/plt/e0026f5de4..79f8636e1e</a><br>
>> >><br>
>> >> =====[ One Commit<br>
>> >> ]=====================================================<br>
>> >> Directory summary:<br>
>> >>   52.6% pkgs/racket-pkgs/racket-test/tests/racket/<br>
>> >>   45.6% pkgs/sandbox-lib/racket/<br>
>> >><br>
>> >> ~~~~~~~~~~<br>
>> >><br>
>> >> 79f8636 Jay McCarthy <<a href="mailto:jay@racket-lang.org">jay@racket-lang.org</a>> 2013-11-22 14:25<br>
>> >> :<br>
>> >> | Ensure that threads created within call-with-limits are accounted<br>
>> >> | during the time/space limits<br>
>> >> :<br>
>> >>   A pkgs/racket-pkgs/racket-test/tests/racket/sandbox.rkt<br>
>> >>   M pkgs/sandbox-lib/racket/sandbox.rkt               | 81<br>
>> >> ++++++++++++++------<br>
>> >>   M .../racket-test/tests/racket/sandbox.rktl         | 48 ++++++++----<br>
>> >>   M .../scribblings/reference/sandbox.scrbl           |  4 +<br>
>> ><br>
>> > --<br>
>> >           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:<br>
>> >                     <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a>                   Maze is Life!<br>
>><br>
>> _________________________<br>
>>   Racket Developers list:<br>
>>   <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>