>From: Takashi Kato <xxxxxx@ymail.com>
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