Just to all be on the same page, could you share how exactly you start with a single thread? Is it something like
(setq hunchentoot::*supports-threads-p* nil)
before you call hunchentoot:start?
Note that *supports-threads-p* is not exported (need double ::'s).
In any case, I think a good start would be to have documented way to choose single vs. multithreaded. And it should not be confused with the having the capability or not, so I think it should be a different variable. I guess on a non-*support-threads-p* platform, it could be an error to choose multithreaded, but otherwise, I'd like a high-level way to choose.
But I'm very new to this, so please forgive me if I'm lost and missed something, as is probably the case.
Thanks,
Mark
----- Original message ----- From: "Hans Hübner" hans.huebner@gmail.com To: [...] Date: Wed, 25 May 2011 11:50:59 +0200 Subject: Re: [hunchentoot-devel] slime foreground buffer for hunchentoot
On Wed, May 25, 2011 at 11:26 AM, Jesse Alama jesse.alama@gmail.com wrote:
On 2011-05-25 06:43:00 +0200, Hans Hübner said:
On Tue, May 24, 2011 at 8:27 PM, Mark H. David mhd@yv.org wrote:
I'm interested in having the ability to break, trace, etc., all the functions running in Hunchentoot. Is there any trick for this? I'd really like to ideally have a SLIME REPL buffer dedicated to it.
I don't know about a dedicated Slime buffer, but I run Hunchentoot single-threaded when I need to debug something in the request execution path. That blocks the REPL buffer, but works well for many situations.
Do you have a flexible way to switch to a single-threaded hunchentoot?
No, the start functions in my applications usually accept a singled-threaded-p argument or something similar. I'm open to suggestions how Hunchentoot could be improved to make switching between multi and single-threaded modes easier, if required.
-Hans
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel