[cc'ed to hunchentoot list] I can confirm that ccl+hunchentoot on OS X 10.6 does not crash in ssl at a concurrency of 20 after 100,000 accesses (100% success in apache bench), whereas before it would crash after a few hundred. However, SBCL 1.0.47 is still freezing, but not coredumping. It just times out on the apachebench side, and in slime both the *inferior-lisp* and *slime-repl* stop responding, and the CPU is pegged at 100%. Using the toy server below, ab also causes an eventual freeze in sbcl but with CCL it mostly works, sometimes giving "SSL read failed - closing connection," which might be the fault of a premature close in the toy server (but I don't see how to do it otherwise, besides waiting until the client side closes). So this isn't a hunchentoot problem, most likely. Given that CCL+hunchentoot works perfectly maybe the problem is inside SBCL, or maybe just the Mac version of SBCL if other platforms now work. -John ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; toy https server ;; (eval-when (load eval compile) (require 'cl+ssl) (require 'bordeaux-threads) (require 'usocket)) (defparameter *keyfile* "./server.key") (defparameter *certfile* "./server.crt") ;; the bad server associates an SSL with the client inside a ;; worker thread, not inside the main thread (defun test-https-server (&key (port 8080) (cert *certfile*) (key *keyfile*)) (format t "~&SSL server listening on port ~d~%" port) (let ((server (usocket:socket-listen "127.0.0.1" port :backlog 100))) (loop (let* ((socket (usocket:socket-accept server)) (stream (usocket:socket-stream socket))) ;; launch response in a separate thread (bordeaux-threads:make-thread (lambda () ;; MAKE SSL HERE (let ((client (cl+ssl:make-ssl-server-stream stream :external-format '(:iso-8859-1 :eol-style :lf) :certificate cert :key key))) (unwind-protect (progn (format client "HTTP/1.0 200 OK~%") (format client "Server: SSL-TEST/1.1~%") (format client "Content-Type: text/plain~%") (terpri client) (format client "HELLO WORLD") (finish-output client)) ;; maybe apachebench is surprised by this close? (close client))))))))) On Apr 3, 2011, at 3:26 AM, David Lichteblau wrote:

Hi,

Quoting David Lichteblau (david@lichteblau.com):

...

Quoting JTK (jetmonk@gmail.com): [...]

...

I've appended a test case in which I think I may have found the source of hunchentoot's problems with ssl and concurrency.

Does the attached patch help?

I have committed an updated version of the patch to CL+SSL CVS now.

This version works now because it avoids use of buggy code in the bordeaux-threads backend for SBCL.

It passes ab testing on SBCL for me; I haven't rechecked other Lisps yet.

...

It's done from Lisp, and should really be done directly in C, similar to the th-lock.c sample code from OpenSSL. But let's first check whether it addresses the issue at all.

If anyone is interested in developing a C version, let's move to that ultimately. But I've decided to commit the Lisp version for now, because I think that correctness should come before performance in this case.

d.

_______________________________________________ cl-plus-ssl-devel mailing list cl-plus-ssl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel