Fare,
I like the general idea, but I think it would be better to encapsulate the actual thread starting in Hunchentoot. The patch you proposed puts the burden of starting threads onto the user.
I would suggest:
(defgeneric make-thread-function (taskmaster thunk) (:method ((taskmaster t) thunk) thunk)))
I like the general simplification with the introduction of start-thread, but that GF should not be part of the public interface. Also, the arguments should be (taskmaster thunk &key name). I see no reason to leave the argument list open as start-thread is meant to be called only from within Hunchentoot.
Documentation updates are missing.
Let me know what you think. -Hans
On Thu, Mar 21, 2013 at 8:54 PM, François-René Rideau < notifications@github.com> wrote:
Introduce start-thread as an entry point so specialized taskmasters can wrap bindings and condition handlers around hunchentoot new thread thunks.
Note that LispWorks and non-LispWorks should probably do the same thing wrt starting a thread for the acceptor or not. I chose to always start a thread, as per the non-LispWorks default. That choice could be reversed. But it's probably bad practice to let the LW and non-LW versions diverge on such a point.
You can merge this Pull Request by running
git pull https://github.com/fare/hunchentoot master
Or view, comment on, or merge it at:
https://github.com/edicl/hunchentoot/pull/52 Commit Summary
- Introduce start-thread as an entry point so specialized taskmasters
File Changes
- *M* packages.lisphttps://github.com/edicl/hunchentoot/pull/52/files#diff-0(2)
- *M* taskmaster.lisphttps://github.com/edicl/hunchentoot/pull/52/files#diff-1(111)
Patch Links: