On Thu, Oct 22, 2015 at 09:51:05PM +0200, Casper.Dik@oracle.com wrote:

quoted

On Thu, Oct 22, 2015 at 08:24:51PM +0200, Casper.Dik@oracle.com wrote:

quoted

The external behaviour atomic; you cannot distinguish the order
between the closing of the original file (and waking up other threads
waiting for a record lock) or changing the file referenced by that newfd.

But this not include a global or process specific lock.

Interesting...  Do you mean that decriptor-to-file lookup blocks until that
rundown finishes?

For that particular file descriptor, yes.  (I'm assuming you mean the 
Solaris kernel running down all lwps who have a system in progress on that 
particular file descriptor).  All other fd to file lookups are not blocked 
at all by this locking.

It should be clear that any such occurrences are application errors and 
should be hardly ever seen in practice.  It is also known when this is 
needed so it is hardly even attempted.

Ho-hum...  It could even be made lockless in fast path; the problems I see
are
	* descriptor-to-file lookup becomes unsafe in a lot of locking
conditions.  Sure, most of that happens on the entry to some syscall, with
very light locking environment, but... auditing every sodding ioctl that
might be doing such lookups is an interesting exercise, and then there are
->mount() instances doing the same thing.  And procfs accesses.  Probably
nothing impossible to deal with, but nothing pleasant either.
	* memory footprint.  In case of Linux on amd64 or sparc64,
main()
{
	int i;
	for (i = 0; i < 1<<24; dup2(0, i++))	// 16M descriptors
		;
}
will chew 132Mb of kernel data (16Mpointer + 32Mbit, assuming sufficient ulimit -n,
of course).  How much will Solaris eat on the same?
	* related to the above - how much cacheline sharing will that involve?
These per-descriptor use counts are bitch to pack, and giving each a cacheline
of its own...  <shudder>