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?
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.
Any opinions?
--binghe
[1] http://www.lispworks.com/documentation/lw51/LWUG/html/lwuser-149.htm#pgfId-8...
"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?
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.
In Lisp, automatic ressource deallocation is most often done in the cleanup clauses of an UNWIND-PROTECT that's nicely abstracted in some WITH-FOO macro.
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.
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.
-T.
On Wed, Oct 1, 2008 at 12:02 PM, Tobias C. Rittweiler tcr@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.
"Erik Huelsmann" writes:
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 think it's reasonable for the library to hook into the garbage collector, and warn about garbage-collected but not yet closed external ressources (and close them, incidentally.)
It should, however, not try to make the user think that relying on the GC for closing external ressources is a good design choice.
-T.
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.
I'm quite sure that only UDP stuff being affected (which haven't been merged into USOCKET). For TCP, the CL implementation itself will take good care of TCP streams and close the socket fd when streams being GCed.
After more investigation, I think there're two implementations of five (CMUCL, ECL/SBCL, CCL, Allegro CL, LispWorks) need consider this issue: LispWorks and CMUCL. They both operate on raw socket fd.
For LispWorks, I've done my idea on USOCKET-UDP: add a special free action on DATAGRAM-USOCKET, when it's getting GCed, SOCKET-CLOSE will be called on it, and I have to add a new CLOSED-P slot for LispWorks on DATAGRAM-USOCKET to avoid multiple call of SOCKET-CLOSE. See this:
http://cl-net-snmp.svn.sourceforge.net/viewvc/cl-net-snmp/usocket-udp/trunk/...
Test on LispWorks shows above code can work: I create many unconnected DATAGRAM-USOCKET instances but not assign them to any variable. After some time and make sure no */**/*** still point to these instances, do a (HCL:GC-ALL) can get all these socket-fd be closed correctly. I think the issue solved (on LispWorks).
Don't know if CMUCL has related function to do the same thing (yet).
-- binghe
-
Chun Tian (binghe) -
Erik Huelsmann -
Tobias C. Rittweiler