current fd allocation idiom

[Mateusz Guzik]

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 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.
> 

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>