8223353: (ch) Change channel close implementation to not wait for I/O threads

[Florian Weimer]

* Alan Bateman:

> On 06/05/2019 10:57, Florian Weimer wrote:
>> :
>> What about resource consumption?
>>
>> I think without #3, an application will have to synchronize with the
>> threads performing I/O on the channel being closed before it can safely
>> create a new channel, to ensure that the actual close (and resource
>> deallocation) happens before the creation of the new channel.
>>
>> Based on your description of the current behavior, it should be possible
>> to create a new channel immediately after closing the old one because
>> the close call only returns after the scarce resource (the file
>> descriptor) has been deallocated.  I'm pretty sure this predictable
>> behavior would be lost.
>>
> The socket/connection is closed at step #1, it's only the final
> release of the file descriptor (connected to one of a pipe) that is
> delayed.

But that descriptor consumes a slot in the descriptor table, which is an
extremely scarce resource.  It does not matter that the file description
used magic I/O inhibition is shared and therefore consumes very little
kernel resources.  The original file descriptor is still occupied until
the lazy close completes and cannot be reused for creating new channels.

Thanks,
Florian