[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