On Friday, November 27, 2015 at 3:44:20 AM UTC+1, Robby Findler wrote:
> Yes, I think you're right. I originally wrote that because I was
> thinking that this code might be involved in evaluating the user's
> submission, but I am not pretty sure I was wrong about that.
"not pretty sure"?
AFAICS, `auto-reload-value` is used to extract the `checker` binding from the
various checker.rkt. but the lock will not be held while running `checker`.
(Luckily we're not using hooks, I haven't studied that code).
> So, yes I
> agree that putting this into the production server may be worth a try
> (depending on how severe the problem you're having is I suppose).
>
> It may make sense to try it out yourself a little bit between due
> dates or something. I did some testing, but more is better.
Yes, we have a staging server for that, I think these courses were my first
time :-).
As a side note, having proper unit tests is somewhat hard though, many
interfaces seem not designed for testability. (Many side effects get in the
way; fixing this is easyish but tedious).
I'm almost ready to "unit test" checkers, but haven't looked into automatic
submissions.
> Also, while I was reading the code again, however, I noticed that my
> diff didn't have enough syncronization. Here's an improved one.
> (reload-module modspec path)
> (set! proc (dynamic-require modspec procname))))))
> (reload)
> - (lambda xs (reload) (apply proc xs))))
> + (lambda xs (protect (reload)) (apply proc xs))))
> diff --git a/info.rkt b/info.rkt
> index 00a42f9..a5686d5 100644
> --- a/info.rkt
> +++ b/info.rkt
> @@ -11,6 +11,7 @@
> "net-lib"
> "pconvert-lib"
> "sandbox-lib"
> + "rackunit-lib"
> "web-server-lib"))
> (define build-deps '("gui-doc"
> "racket-doc"
>
>
> On Thu, Nov 26, 2015 at 6:23 PM, Paolo Giarrusso wrote:
> > On 25 November 2015 at 14:54, Robby Findler wrote:
> >> I'm still not completely
> >> sure, but since you seem to be able to provoke the error, that
> >> emboldens me to suggest you apply the diff below and see if it goes
> >> away.
> >
> > I'm doing this. Annoyingly, I can't force the crash at will yet, and
> > an automated handin-server stress-tester is not in our plans yet :-|.
> >
> >> That diff is probably not what we'd want in the end, since it is too
> >> much locking (we would want a namespace-specific lock not a global
> >> one) but if the error does go away, that means that this is probably
> >> the right place to put the lock in.
> >
> > Makes sense.
> >
> > But for my production environment, I guess that this patch won't
> > overly restrict concurrency: I guess namespaces correspond to checkers
> > in the handin-server, right? So, since I only ever open one
> > assignment, I should only have one namespace anyway?
> >
> > Cheers,
> > Paolo
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
