Date: Fri, 29 Mar 2013 16:54:31 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Carl Shapiro <carl.shapiro@gmail.com> Cc: freebsd-net@freebsd.org, Andriy Gapon <avg@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130329235431.32D7FB82A@mail.bitblocks.com> In-Reply-To: Your message of "Fri, 29 Mar 2013 14:30:59 PDT." <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com> References: <515475C7.6010404@FreeBSD.org> <CANVK_QgnC-pLGwh7Oad87JO_z1WmLeY3kfT9HhdpSzMnpjdNgA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro <carl.shapiro@gmail.com> wrote: > > In other operating systems, such as Solaris and MacOS X, closing the > descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should return (with EINTR?) so that the blocking thread can some cleanup action. And if you do that, the blocking accept() case is not really different. There is no point in *not* telling blocking threads that the descriptor they're waiting on is one EBADF and nothing is going to happen. > It is not obvious whether there is any benefit to having the current > blocking behaviour. This may need some new kernel code but IMHO this is worth fixing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130329235431.32D7FB82A>