Date: Wed, 20 Aug 2014 11:10:10 -0400 From: John Baldwin <jhb@freebsd.org> To: Benjamin Kaduk <bjk@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Mateusz Guzik <mjguzik@gmail.com>, freebsd-arch@freebsd.org Subject: Re: current fd allocation idiom Message-ID: <201408201110.10431.jhb@freebsd.org> In-Reply-To: <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu> References: <20140717235538.GA15714@dft-labs.eu> <20140813015627.GC17869@dft-labs.eu> <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 15, 2014 7:20:03 pm Benjamin Kaduk wrote: > On Tue, 12 Aug 2014, Mateusz Guzik wrote: > > > On Tue, Aug 12, 2014 at 09:31:15PM -0400, Benjamin Kaduk wrote: > > > On Tue, Aug 12, 2014 at 7:36 PM, Mateusz Guzik <mjguzik@gmail.com> wrote: > > > > > > > I would expect soabort to result in a timeout/reset as opposed to regular > > > > connection close. > > > > > > > > Comments around soabort suggest it should not be used as a replacement > > > > for close, but maybe this is largely because of what the other end will > > > > see. That will need to be investigated. > > > > > > > > > > > I added some text regarding soabort to socket.9 in r266962 -- does that > > > help clarify the situation? > > > > > > > Nope. :-) > > > > It is unclear if the only motivation here is making sure nobody else > > sees the socket when given thread calls soabort. This would be easily > > guaranteed in here: fd allocation failed, fp with given socket was never > > exposed to anyone. > > > > So, if you say soabort would work here just fine, I'm happy to use it > > and blame you for problems. :-) > > Hmm, I was hoping that jhb would chime in and save me from being on the > hook, but it does look like soabort() would be acceptable in this case. I think having the EMFILE/ENFILE case use the same exact logic as a listen queue overflow (i.e. soabort()) is correct. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408201110.10431.jhb>