> Thank you. I merged this in to sbcl-0.9.1.16, along with a couple of
> test cases. In doing so, I decided that it was weird to me that
> (socket-open-p (make-instance 'inet-socket :type :stream :protocol :tcp=
> would return true despite (presumably) any attempt to write to the
> socket producing an error. I am by no means a socket expert, so I
> leave it to you to judge whether this is sensible or not.
I'm a fellow non-socket expert, but I'll opine anyway. The
make-instance call wraps a C socket() call, that is, it asks the OS to
reserve a socket resource, and it gives us a reference to the
allocated resource (the FD). So socket-open-p isn't really a
predicate which tests for connectedness to the "other end" (which I
assume is the scenario which makes you feel uneasy) but for OS socket
allocation ("connectedness to the OS", perhaps).
For example, if the protocol is not connection-oriented (UDP, say),
then attempts to write to the socket /will/ work. If the protocol
/is/ connection-oriented (TCP or SCTP), then I agree, since the
connection is not yet up, writes on the socket will fail. But the
socket resource has been allocated: the FD is the app's handle to the
OS socket resources, /not/ a measure of it's connectedness to the
"other end". Does this reduce the wierd-o-meter level?
Apologies for the utterly personal terminology above, I learnt about
sockets by hacking on them, mostly through sb-bsd-sockets, not from
Thanks very much,