Re: [Qitab-devel] A problem of quux-hunchentoot and its solution
+ qitab-devel On Apr 25, 2014, at 15:00 , 昊 谢 <xiehao@outlook.com> wrote:
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
Dear xiehao, thank you for excellently diagnosing this issue. I have pushed a fix that I think is more robust, but it is wholly untested, so please tell me if it works for you. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org My hobby of not attending meetings about recycling saves more energy than your hobby of recycling. — John McCarthy On Thu, Apr 24, 2014 at 11:03 PM, 昊 谢 <xiehao@outlook.com> wrote:
+ qitab-devel
On Apr 25, 2014, at 15:00 , 昊 谢 <xiehao@outlook.com> wrote:
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
Hi fahree, It works on my OSX 10.9.2, sbcl 1.1.17, and hunchentoot 1.2.26. Although I haven’t tested it on the other environments, I think it should be. Thank you. On Apr 25, 2014, at 18:11 , Faré <fahree@gmail.com> wrote:
Dear xiehao,
thank you for excellently diagnosing this issue. I have pushed a fix that I think is more robust, but it is wholly untested, so please tell me if it works for you.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org My hobby of not attending meetings about recycling saves more energy than your hobby of recycling. — John McCarthy
On Thu, Apr 24, 2014 at 11:03 PM, 昊 谢 <xiehao@outlook.com> wrote:
+ qitab-devel
On Apr 25, 2014, at 15:00 , 昊 谢 <xiehao@outlook.com> wrote:
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
participants (2)
-
Faré -
昊 谢