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.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-0>(2) - *M* taskmaster.lisp<https://github.com/edicl/hunchentoot/pull/52/files#diff-1>(111)

Patch Links:

- https://github.com/edicl/hunchentoot/pull/52.patch - https://github.com/edicl/hunchentoot/pull/52.diff