current fd allocation idiom
John Baldwin
jhb at freebsd.org
Wed Aug 20 16:00:40 UTC 2014
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 at 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
More information about the freebsd-arch
mailing list