[tbnl-devel] Re: TBNL and Araneida

Bob Hutchison hutch at recursive.ca
Wed Oct 12 12:13:08 UTC 2005


Hi Alan,

You can blame that patch on me, but Edi might have modified it  
somewhat, I don't know. If I can be of any help, please let me know.

I submitted a second patch (well, code really, not a patch) on July  
14 that would be nice for you to have a look at as well. I've  
reproduced it waaay at the bottom of this message.

Cheers,
Bob

On Oct 12, 2005, at 3:46 AM, Edi Weitz wrote:

> Hi Alan!
>
> I'm Cc'ing my replies to tbnl-devel so people there know what's going
> on.
>
> On Tue, 11 Oct 2005 19:44:47 -0500, Alan Shields <Alan- 
> Shields at omrf.ouhsc.edu> wrote:
>
>
>> I don't normally read the TBNL mailing list (sorry!),
>>
>
> Hehe.  No reason to apologize - you don't use it, so why should you
> read the mailing list?
>
>
>> but someone pointed me there today and I noticed one of your users
>> was having trouble, and you recommended a certain patch to Araneida.
>>
>> Just wanted you to know that I'm looking at the patch and figuring
>> out how best to integrate it permanently with Araneida so you can
>> eliminate this nuisance.
>>
>
> Great, thanks.
>
>
>> I might have some questions for you later on if you wouldn't mind.
>>
>
> Sure, no problem.
>
> Cheers,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

----------------- That other change...


> Hi,
>
> I believe I mentioned sometime way back that when connecting to an  
> Araneida server running in LispWorks on OS/X that frequent and  
> apparently spurious error messages indicating some kind of socket  
> problem were being printed. Safari caused many more errors than  
> FireFox, wget none at all. These things were happening at some high  
> frequency (Safari very close to 1 error per real request, Firefox  
> maybe 1 of 4).
>
> Anyway, the messages were beginning to be annoying so I tried to  
> track down the problem. What was happening was that in read-request- 
> from-stream there was an error. I wrapped the call to read-line in  
> a handler and dealt with the comm::socket-error that lispworks was  
> providing. I also prevented the handling of the now null request. I  
> then modified the do-it function in with-accept-flets to not do-it  
> if read-request-from-stream returned nil.
>
> Messages gone.
>
> I don't know if this problem exists in any other configuration. I  
> also don't know what specific condition is raised for other  
> implementations (so the handler-case in read-request-from-stream is  
> pretty spartan).
>
> Cheers,
> Bob


---- somewhere in daemon.lisp --------

(defun read-request-from-stream (listener stream)
   (let ((first-line nil))
     (handler-case (setf first-line (read-line stream nil nil))
       #+lispworks(comm::socket-error (condition)
                                      (progn
                                        (setf first-line nil))))
     (when first-line
       (let ((default-hostname (when (slot-boundp listener 'default- 
hostname)
                                 (http-listener-default-hostname  
listener))))
         (read-request-from-stream/guts first-line default-hostname  
stream)))))


---- somewhere in http-listener.lisp --------

(defmacro with-accept-flets (&body body)
   `(labels ((do-it (listener s)
         (let ((r (read-request-from-stream listener s)))
                 (when r
                   (handler-case
                       (handle-request-using-listener
                        listener (http-listener-handler listener) r)
                     (response-sent () nil)
                     (http-error (c)
                                 (request-send-error r (http-error- 
code c)
                                                     (http-error- 
message c)))))))
       (accept (listener)
               (listener-accept-stream listener)))
      (with-simple-restart
    (abort-response "Abort this response and answer another request")
        ;; expectation is that socket-accept will not block, because we
        ;; are invoked when select() says something is ready.  we really
        ;; ought to set the master socket non-blocking to be sure.
        (let ((*debugger-hook* #'handler-debugger-hook))
    , at body))))




More information about the Tbnl-devel mailing list