HI Francois-Rene Rideau, qitab-devel,

I encountered a problem when I’m using your quux-hunchentoot and I have a simple way to fix it. Could you please consider it?

When I’m using the thread-pooling taskmaster and starting acceptor, there may be an error invoked occasionally like this:

debugger invoked on a SIMPLE-ERROR in thread

#<THREAD "quux-hunchentoot-dispatcher-*:8080" RUNNING {10035DDF03}>:

  The assertion

  (EQ QUUX-HUNCHENTOOT::DISPATCHER-PROCESS (BORDEAUX-THREADS:CURRENT-THREAD))

  failed with QUUX-HUNCHENTOOT::DISPATCHER-PROCESS = NIL,

  (BORDEAUX-THREADS:CURRENT-THREAD) =

  #<SB-THREAD:THREAD "quux-hunchentoot-dispatcher-*:8080" RUNNING {10035DDF03}>.

I think the reason for this is quite straightforward. While the method “execute-acceptor” is creating dispatcher thread and set it by the dispatcher-process accessor of taskmaster, we can’t imagine the “setf” action comes first. In other words, if dispatcher thread started before the accessor was set, the assertion in ensure-dispatcher-process may fail.

My solution for this is quite simple and here’s the effective solution, adding something like a spin-lock.

diff --git a/thread-pooling.lisp b/thread-pooling.lisp

index dcb3427..8f3f32b 100644

--- a/thread-pooling.lisp

+++ b/thread-pooling.lisp

@@ -146,6 +146,7 @@ then the reply will be HTTP 503."))

 

 (defmethod ensure-dispatcher-process ((taskmaster thread-pooling-taskmaster))

   (with-taskmaster-accessors (dispatcher-process) taskmaster

+    (do () (dispatcher-process) (sleep 0.1))

     (assert (eq dispatcher-process (bt:current-thread)))))

 

 (defmethod decrement-taskmaster-accept-count ((taskmaster thread-pooling-taskmaster))

Maybe you can get a better patch to solve this problem and I’m looking forward your reply.

Thanks & have a good day

Hao Xie