On Sunday, November 29, 2015, Paolo Giarrusso <p.giarru...@gmail.com> wrote:
> 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"?
Sorry. No "not".
>
> 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).
Yes that's also what I noticed and why I sent a second diff. Or did I miss
another place?
Robby
>
> > 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 racket-users+unsubscr...@googlegroups.com <javascript:;>.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
