[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: socket-port

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.