[usocket-devel] Re: What if a usocket instance be garbage collected?

[Erik Huelsmann]

On Wed, Oct 1, 2008 at 12:02 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> "Chun Tian (binghe)" writes
>
>> Hi, usocket devel
>>
>> If a usocket instance has been garbage collected (or just cannot refer
>> to it, i. e. lost it by set the variable to new value), does anyone
>> (either usocket or CL platform) will consider closing the correspond
>> socket fd automatically?

Well, in case of using a socket as supported by the underlying
implementation, the implementation will take care of closing the
socket.

> I think the general consensus is not to misuse the Garbage Collector as
> a general ressource manager. You never know when GC is run, if it's run
> at all, etc.

Right. However, if the object refering to some external resource is
not explicitly closed, you might want to do so if the object is
garbage collected.

> In Lisp, automatic resource deallocation is most often done in the
> cleanup clauses of an UNWIND-PROTECT that's nicely abstracted in some
> WITH-FOO macro.

Yes, however, from the point of view of the library, this can't be
guaranteed. If the library can make sure the resources will be
de-allocated, I'm of the opinion it should.

>> I know at least one CL platform, LispWorks, has some related API
>> (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP
>> applications. Just don't know if this will be a common feature to be
>> considered by usocket itself.

It doesn't need to be applied to other backends in general, however,
it does need to be applied to all implementations which make direct
use of the handles (non-lisp objects) supplied by the operating
system.

> The usual terminology for this kind of stuff is "finalizers". What you
> could do, is to add a finalizer that signals a warning if a socket
> object is going to be garbage collected that wasn't closed previously.

Right. However, implementations which provide objects for this purpose
should take care of this themselves because usocket uses the
implementation supplied sockets. Only in those cases where such
guarantees are missing, usocket needs to take additional measures.
This includes LispWorks, but additional investigation will turn up if
this is the only implementation affected.

Bye,

Erik.