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

Patch Links: