Date: Sun, 24 Aug 2014 12:15:59 +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: <20140824101559.GB2045@dft-labs.eu> In-Reply-To: <20140824095901.GA2045@dft-labs.eu> 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> <20140824095901.GA2045@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 24, 2014 at 11:59:01AM +0200, Mateusz Guzik wrote: > 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; > Erm, of course we need to make sure fdtable is not going to be allocated from under us and we would need seqeuence counters or something else to ensure we updated proper copy and however was messing with it sees the update. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140824101559.GB2045>