This page is part of the web mail archives of SRFI 106 from before July 7th, 2015. The new archives for SRFI 106 contain all messages, not just those from before July 7th, 2015.
From: Takashi Kato <ktakashi@xxxxxxxxx> Subject: Re: socket-port Date: Wed, 19 Jun 2013 22:01:23 +0200 > Now, think about multi process what should happen on GCing socket? > (I'm not even sure how socket object can be passed to other process > since the srfi doesn't have any way to create it passing fd though.) I think sharing socket fd happens more often when the process which opens the socket spawns a child process, rather than passing socket fd explicitly. Either way, it's certainly out of scope of this srfi. We just need not to interfere systems that's capable to share socket fds. > To me, it's reasonable to cleanup since no srfi nor standards mentions > multi process, or is it better to be unspecified so that > implementations have space to expand? If GC doesn't shutdown the socket, there'll be a risk of resource leaks from a sloppy program; on the other hand, if GC does shutdown the socket, a sloppy parent program may cause sporadic and hard-to-reproduce failures in child process, when the parent process GCs the socket that is still in use in the child. Either way is bad, so I suggest to make it clear that it's program's responsibility to close and/or shutdown the socket explicitly, and GC is there just for a safety net. If the program wishes to keep the socket alive, just close it (GC shouldn't shutdown a socket that is closed state). Whether GC shutdown a socket that's not closed, we can leave it to the implementation, since there's no correct choice. --shiro