[Openmcl-devel] Who uses CL+SSL and CCL?
john at mcaleely.com
Fri Jan 16 03:29:28 PST 2009
On 16 Jan 2009, at 01:59, Gary Byers wrote:
> I was able to reproduce the problem. I know next to nothing about
> using SSL; so so far I only have a very general idea of what's
> going on.
It's good to know I'm not going mad.
> TEST-HTTPS-SERVER does:
> (let* ((socket (trivial-sockets:accept-connection
> :element-type '(unsigned-byte 8)))
> (client (cl+ssl:make-ssl-server-stream
> (cl+ssl:stream-fd socket)
> :external-format :iso-8859-1
> :certificate cert
> :key key)))
> So, without looking at that too closely, it -looks- like SOCKET and
> CLIENT share the same file descriptor.
> (close socket) ; possibly closing the shared fd
> (close client) ; possibly forcing output to the closed fd
> If that's what's going on, it can't work (or at least can't work
> in general.) If I add
> (force-output client)
> just before those two CLOSE calls, I get output in the web browser and
> in the listener that's running the server example, and the server
> waits for the next connection.
I can reproduce this result. I think my own naive understanding of
what is going on would call the order of calls to close a bug. The
cautious part of me would want to close the client before the socket,
since they appear to have some sort of dependency.
I could well imagine other implementations where this hasn't been
exposed as a problem. Is it possible that a recent change in CCL has
surfaced this bug in the CL+SSL test code?
I'm happy that making this change is an appropriate way to fix this
> Lastly, I tried this in the CCL trunk (and got the same error that you
> did.) I don't think that anything that's changed since 1.2-RC1
> would affect this, but there were bug fixes between 1.2-RC1 and
> the final version of 1.2, and there are post-1.2 fixes in the 1.2
> tree, so you might avoid other problems by upgrading.
It's on my todo list, but CCL is also on my 'if it ain't broke...' list.
More information about the Openmcl-devel