From fahree at gmail.com  Wed Apr 16 15:42:49 2014
From: fahree at gmail.com (=?UTF-8?B?RmFyw6k=?=)
Date: Wed, 16 Apr 2014 11:42:49 -0400
Subject: [Qitab-devel] cl-protobufs
Message-ID: <CAN7nBXeZuV9fp74x8F-C-a8aSgPD3z+NYqNYrv9NPVsi+eZuNw@mail.gmail.com>

Is anyone using cl-protobufs beside the QPX team at Google (n?e ITA)?

Our resident speed junkies have slightly incompatible changes under
the hood, such as using defstruct instead of defclass.

If you're impacted by this, positively or negatively, we're interested
in hearing from you. I see that nothing in quicklisp uses
cl-protobufs, but someone could be using it privately, I'm sure.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
If you want to do good, work on the technology, not on getting power.
        ? John McCarthy



From xiehao at outlook.com  Fri Apr 25 03:03:14 2014
From: xiehao at outlook.com (=?utf-8?B?5piKIOiwog==?=)
Date: Fri, 25 Apr 2014 15:03:14 +1200
Subject: [Qitab-devel] A problem of quux-hunchentoot and its solution
In-Reply-To: <686463F8-9DA4-471F-BA29-53AB4441445D@outlook.com>
References: <686463F8-9DA4-471F-BA29-53AB4441445D@outlook.com>
Message-ID: <BLU0-SMTP40019311597F2A89B4DC12FCE5A0@phx.gbl>

+ qitab-devel

On Apr 25, 2014, at 15:00 , ? ? <xiehao at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/qitab-devel/attachments/20140425/cbe328a1/attachment.html>

From fahree at gmail.com  Fri Apr 25 06:11:23 2014
From: fahree at gmail.com (=?UTF-8?B?RmFyw6k=?=)
Date: Fri, 25 Apr 2014 02:11:23 -0400
Subject: [Qitab-devel] A problem of quux-hunchentoot and its solution
In-Reply-To: <BLU0-SMTP40019311597F2A89B4DC12FCE5A0@phx.gbl>
References: <686463F8-9DA4-471F-BA29-53AB4441445D@outlook.com>
 <BLU0-SMTP40019311597F2A89B4DC12FCE5A0@phx.gbl>
Message-ID: <CAN7nBXdDx7tfwgG2nHUGG_LkESS2smnRZ6TeuuC5HT5OghovQg@mail.gmail.com>

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 at outlook.com> wrote:
> + qitab-devel
>
> On Apr 25, 2014, at 15:00 , ? ? <xiehao at 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
>



From xiehao at outlook.com  Fri Apr 25 06:21:12 2014
From: xiehao at outlook.com (=?utf-8?B?5piKIOiwog==?=)
Date: Fri, 25 Apr 2014 18:21:12 +1200
Subject: [Qitab-devel] A problem of quux-hunchentoot and its solution
In-Reply-To: <CAN7nBXdDx7tfwgG2nHUGG_LkESS2smnRZ6TeuuC5HT5OghovQg@mail.gmail.com>
References: <686463F8-9DA4-471F-BA29-53AB4441445D@outlook.com>
 <BLU0-SMTP40019311597F2A89B4DC12FCE5A0@phx.gbl>
 <CAN7nBXdDx7tfwgG2nHUGG_LkESS2smnRZ6TeuuC5HT5OghovQg@mail.gmail.com>
Message-ID: <BLU0-SMTP1186311F2D8233DE3EB46ABCE5A0@phx.gbl>

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 at 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 at outlook.com> wrote:
>> + qitab-devel
>> 
>> On Apr 25, 2014, at 15:00 , ? ? <xiehao at 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
>> 
>