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@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@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)) ,@body))))