[hunchentoot-devel] less-than-helpful error message
Hans Hübner
hans.huebner at gmail.com
Wed Jun 23 09:52:16 UTC 2010
Hi,
Edi and I discussed this matter and we agreed that my suggestion that
using a recursive lock would solve the problem does not really hold.
With the same situation (error signaled while holding the lock and
logging, resulting in another log invocation), the recursive lock
would result in an infinite recursion and finally stack exhaustion.
This would not be an improvement.
I think Dan's contribution was good: It should be attempted to do
fine-grained error handling for the arguments while logging, and
errors while logging should certainly not make the code re-enter the
logging code.
Cyrus, did you actually verify that your patch solves the problem? We
might be missing something.
Thanks,
Hans
On Wed, Jun 23, 2010 at 08:40, Edi Weitz <edi at agharta.de> wrote:
> Cyrus,
>
> Thanks for the patch, but I'm order for this one to be accepted it
> should work for LispWorks as well. I'd look into it myself, but I
> currently have problems with my arm/shoulder which prevent me from
> sitting at my desk for longer periods.
>
> Cheers,
> Edi.
>
>
> On Wed, Jun 23, 2010 at 8:33 AM, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
>> I have no idea if this is the right thing to do for lispworks or not, but this seems to work on SBCL.
>>
>>
>>
>>
>> Thanks,
>>
>> Cyrus
>>
>> On Jun 15, 2010, at 9:39 PM, Hans Hübner wrote:
>>
>>> On Wed, Jun 16, 2010 at 01:49, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
>>>> So, while trying to track down an unrelated issue where my handlers aren't getting called anymore, I came across the following issue where failure to open the message log file results in an error, which, in turn, attempts to open the message log file. The problem in this case was that the permissions were bogus for the directory I was trying to open. But, still, we should probably have a nicer error message than "recursive lock attempt" here.
>>>
>>> I agree. Can you supply a patch that corrects the problem? Using a
>>> recursive lock would probably the easiest solution.
>>>
>>> Thanks,
>>> Hans
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
More information about the Tbnl-devel
mailing list