On Jun 6, 2007, at 11:45, Nikodemus Siivola wrote:
> Socket-make-stream cancels the finalization for the socket object,
> but doesn't create the new stream with :auto-close by default -- so
> the FD ends up without a finalizer.
> This doesn't seem right to me. Of course, part and parcel of the
> problem is that after creating the stream both objects hold the FD,
> and automatically closing the FD just because either one is
> collected seems not-quite-right.
> I think TRT would be to keep the finalizer on the socket, and hold
> a pointer to the socket from the fd-stream, so that the
> finalization cannot happen as long as the stream exists.
> Am I thinking straight?
FWIW, I think so.
I've had some thoughts on the matter from my application's use of
fds, and I'd like to propose an extension to this:
Yes, the stream holds the socket. Furthermore, SOCKETs get a new
superclass; call it FD-CELL, or perhaps FILE (as in 'file descriptor'
but not any more a descriptor). An object of this class holds a FD
and closes it when garbage collected, or when explicitly told to
(stdin/stdout/stderr, due to their special positions, might have
special FILEs without finalizers.)
If one retains and passes the FILE instead of the FD, it is then
impossible to accidentally use a FD that has been closed (and
possibly reassigned). This could be supported by having operations
which currently take a FD take a FILE instead; SB-SYS:ADD-FD-HANDLER
would especially benefit, reducing the opportunities for invalid
Also, NON-BLOCKING-MODE should be made an operation on FILEs instead
of sockets; it's useful for any fd, and I'd be able to remove some
copy-and-paste from sb-bsd-sockets from my application.
If this seems reasonable, I would be interested in attempting to
Kevin Reid <http://homepage.mac.com/kpreid/>