Hi guys, Edi, I responded to your email last week but, by accident, didn't cc you. I told Pete I had just started my first Debian stable -> unstable upgrade and that my world was torn apart. The upgrade was a bear for me but I finally have the pieces glued back in place, at least enough to do rough work. I now know more than I did about X, BlackBox, KDE, apt-get, dselect, and all that jazz. A couple of things. Edi, your aborted connection patch is a good thing. I don't remember if you noted that the aborted connections never happen until after ab completes its run. It seems to me that the there is one additional request sent to mod_lisp as each httpd process terminates. I used the Apache logging feature and did 'tail -f error_log' to watch what happens as ab runs. Everything was fine until after ab completed. Then and only then did the aborted connection logs start appearing. I didn't measure it exactly but it seemed the messages dribbled along as httpd's terminated after reaching their approx. 150 peak. I put in enough log messages to verify that with ab -n 2000 -c 200, I got about 2199 total messages, of which 199 ended with aborts. With ab -n 2000 -c 1, there were no aborts. With ab -n 2000 -c 2, there was 1 abort. I was unable to find any fields in the request_rec that indicated that the request was a "duplicate". I set flags in the .. from memory, what are the functions, lib_child_init and lib_child_exit? .. but the "extra" call comes before any call to lib_child_exit. The requests are all full ones, and TBNL gets the full request and generates a full response, even through more requests are made than are asked for with ab's -n parameter. I'll do more research, for example looking at other Apache module's source code, and google searches, or writing a custom ab, when I get a chance. Tonight I'm leaving for vacation. I'm taking my laptop but my time and access will be occasional only. I'll be back the second Tuesday after today. In create-static-file-dispatcher-and-handler, I'm pretty sure the make-array is thread unsafe where it sits. Aren't only special variables thread safe? The code as is establishes the closure at best when the dispatch table is constructed. With multiple threads, they each are sharing buf, which isn't good for several reasons. In CMUCL, I got lots of "bad address" errors in a function underneath read-sequence on the stream reading fz.jpg. The errors seemed to go away when I moved the let/make-array inside the handler. Sorry I don't have time for a real test or real patches but I hope to be on the road in an hour. It's great to see an active tbnl-devel. Jeff --- Stefan Scholl <stesch@no-spoon.de> wrote: ...

(defun create-static-file-dispatcher-and-handler (uri path content-type) "Creates a dispatch function which will dispatch to a handler function which emits the file PATH with CONTENT-TYPE if the URI matches the SCRIPT-NAME of the request." (let ((buf (make-array 8192 :element-type #-:tbnl-bivalent-streams 'character #+:tbnl-bivalent-streams '(unsigned-byte 8)))) (let ((handler #'(lambda () (setf (content-type) content-type) (with-output-to-string (str) (with-open-file (file path :direction :input

#+:tbnl-bivalent-streams :element-type

#+:tbnl-bivalent-streams '(unsigned-byte 8)) (do ((pos (read-sequence buf file) (read-sequence buf file))) ((zerop pos)) (write-sequence buf str :end pos))))))) #'(lambda (request) (when (equal (script-name request) uri) handler))))) ...

__________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/