Re: why not remove AF_LOCAL sockets on last close?

[Thor Simon <tls%coyotepoint.com@localhost>]

On Fri, Jun 25, 2010 at 10:06:41AM -0400, Greg Troxel wrote:
> 
> >> Have you looked at posix to see if it speaks to this?  I don't think it
> >> gets specific enough to say.

I can't actually find any discussion of this (dumb) behavior anywhere
but in the bind(2) manual page.  However, it looks like it's probably
been described there since 4.2BSD (I don't have the actual 4.2BSD
manual pages handy but it is in both the SunOS 4 and 2.10BSD pages).

> I don't know, and if you've got an argument that code written for either
> behavior will be ok both places I don't have a problem with it.  The
> only thing I can think of is that code that does an explicit unlink and
> checks for error on the unlink may complain, which is pretty mild.

Code written to not unlink wouldn't be OK on systems that require the
unlink.  But code written to do the unlink would continue to work
anywhere -- it will just work better now, in that if it exits early
(and, you know, programs do tend to do that ;-)) the file will go
away from the filesystem, rather than sitting there as a riddle for
whatever person or process is left to clean it up.

I could make this a socket option.  I'm just wondering if I really
should.  Changing the default behavior seems very appealing to me
because it would actually retroactively "fix" buggy old programs
with almost no downside.

Thor