[hunchentoot-devel] with-recursive-lock-held

Nick Allen rflug05 at gmail.com
Thu Jul 31 20:41:38 UTC 2008


Hello,
The session value / recursive lock stuff all seems to work as of rev #3712.

thanks for the quick response, keep up the good work!

Nick

On Thu, Jul 31, 2008 at 6:03 PM, Hans Hübner <hans at huebner.org> wrote:

> Hi Nick,
>
> thank you for your detailed report.  I think I have fixed the problem,
> can you svn up and let me know if it works better?  If not, I'll hack
> on it more so that things get back to a good state tonight.  Sorry for
> the glitch.
>
> Thanks,
> Hans
>
> On Thu, Jul 31, 2008 at 17:43, Nick Allen <rflug05 at gmail.com> wrote:
> > Hello Hans,
> > The specific problem I ran into was a recursive lock error thrown when
> > setting a session value in the same request that starts a session. I'm
> using
> > rev 3591. here's an example:
> >  (defun test-dispatcher (hunchentoot:*request*)
> >    (lambda ()
> >    ;; set the session value FOO to the value of
> >    ;; the HTTP get parameter "set-foo", if it
> >    ;; exists
> >    (let ((set-foo (hunchentoot:get-parameter "set-foo")))
> >      (when set-foo
> >        (setf (hunchentoot:session-value 'foo) set-foo)))
> >    ;; then return a page that shows the session
> >    ;; value FOO
> >    (format nil "The foo is ~A" (hunchentoot:session-value 'foo))))
> >
> > ;; start the server
> > (pushnew 'test-dispatcher hunchentoot:*dispatch-table*)
> > (defvar *test-server* (hunchentoot:start-server :port 2001))
> > ;; now go to:
> > ;;
> > ;;    http://localhost:2001?set-foo=bar
> > ;;
> > ;; it should look like:
> > ;;
> > ;;    The Foo is bar
> > ;;
> > ;; but it throws a recursive lock error
> > On Thu, Jul 31, 2008 at 7:09 AM, Hans Hübner <hans at huebner.org> wrote:
> >>
> >> Hi Nick,
> >>
> >> thank you for reporting a problem - Can you provide me with details on
> >> how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for
> >> Lispworks?  I have removed it because I believed that there is no code
> >> path that could be to recursive locking, but I could have been missing
> >> something.
> >>
> >> In general, the Subversion repository is less stable than Edi's
> >> releases and we are planning to make a proper release, yet I can't
> >> make any promises.
> >>
> >> Thanks,
> >> Hans
> >>
> >> On Thu, Jul 31, 2008 at 03:58, Nick Allen <rflug05 at gmail.com> wrote:
> >> > Hello!
> >> > Is the "ediware" location of the hunchentoot source the recommended
> >> > version
> >> > for deployment? or should we be using the tarball linked off the
> >> > documentation or the "hans" version?  I'm wondering because
> >> > WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of
> >> > "lispworks.lisp",
> >> > which seems to have introducing some bugs, which seems to me to
> suggests
> >> > to
> >> > me that the "ediware" repo is either out of date or too bleeding
> edge...
> >> > take care
> >> > Nick
> >> > _______________________________________________
> >> > tbnl-devel site list
> >> > tbnl-devel at common-lisp.net
> >> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >> >
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080731/3222ede4/attachment.html>


More information about the Tbnl-devel mailing list