Kevin de Berk wrote:
>> I believe I was actually responsible for changing this, somewhat
>> For the record, we didn't take :name off the list of supported keyword
>> arguments, per se. Originally, socket-make-stream just pushed through
>> all its arguments to sb-sys:make-fd-stream, with no checking.
>> I can't see an objection to adding :name to the interface to provide a
>> better display. Note, however, that one would want to think about doing
>> this a little. There would be a benefit to having a client application
>> be able to set a helpful print name, but the downside is losing the
>> ability to tell at a glance whether a stream is a socket stream or not.
>> Perhaps this :name support should be coupled with some enhancement of
>> the print-object method for fd-streams....
>> PS I'm hoping a moderator will push this through to the sbcl-help
>> mailing list, which I don't (and will not) subscribe to.
> Please note that :AUTO-CLOSE is also no longer an accepted keyword
> for SOCKET-MAKE-STREAM. Is this still a supported keyword?
> The only library that uses it, as far as I can see, is ACL-COMPAT and
> with it aserve (the Portable Allegro webserver.) To my knowledge, aserve
> hasn't been been updated for a few years but it is still an important
> element in the final practicals of the Practical Common Lisp book.
All I know is what I just read in the fd-stream source:
(when (and auto-close (fboundp 'finalize))
(format *terminal-io* "** closed file descriptor ~W **~%"
I am not familiar enough with the code to tell under what circumstances
finalize will or won't be fbound.
If it's appropriate, it would certainly be fine to have :auto-close be
restored to the socket-make-stream arglist. If we do, it would be nice
to extend the make-socket-stream docstring to explain the behavior.
A follow-up question for the better-informed than me: would it be
appropriate to have make-fd-stream raise a condition if auto-close is
non-nil, but finalize is not fbound? In that case, the caller is asking
for auto-close behavior, and the calling code has no way of telling that
it will not get the auto-close behavior it expects. This should be a
continuable error so that the interactive caller could react
appropriately at the repl, and savvy programmers could continue through
the error if it's acceptable to them.