Date: Sun, 24 Aug 2014 11:59:01 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Benjamin Kaduk <bjk@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: current fd allocation idiom Message-ID: <20140824095901.GA2045@dft-labs.eu> In-Reply-To: <201408201110.10431.jhb@freebsd.org> References: <20140717235538.GA15714@dft-labs.eu> <20140813015627.GC17869@dft-labs.eu> <alpine.GSO.1.10.1408151916150.21571@multics.mit.edu> <201408201110.10431.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 20, 2014 at 11:10:10AM -0400, John Baldwin wrote: > 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. > So I was playing with converting stuff and I think I hit the wall with procdesc. procdesc is instantianed after fork cannot fail anymore. I'm not so sure we can finish up procdesc for a process which didn't fork yet, and I seriously doubt we can just kill the new process to revert stuff (e.g. what about SIGCHLD or kqueue events which fire). That said, like previously proposed plan would be: where applicable: 1. allocate fp 2. do stuff 3. install fp under free fd in cases like procdesc: 1. reserve fd 2. allocate fp 3. do stuff 4. install fp This introduces a special case to dup2 when newfd is reserved. Linux fails in this case with, so I believe we can get away with it as well. When it comes to avoiding taking filedesc lock multiple times for succeedeing case, we can get away with the following: 1. finit(..); 2. ensure all writes are completed 3. fdp->fd_ofiles[fd].fde_file = fp; -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140824095901.GA2045>