> Posix Std 1003.1-1988, section 5.3.2.1, paragraph 2 says
>
> "The open() function shall return a file descriptor for the named
> file which is the lowest file descriptor not currently open for
> that process."
ok, i knew about this in the first place, i was just curious how
'entrenched' this feature is. Very entrenched, unfortunately. I suppose
it's also in the Posix testsuite.
i still havent seen any (technical) explanation why this is specified this
way, IMHO it's a silly restriction that kills (well, seriously hinders) a
fast+scalable file handling redesign.
normal code really doesnt need to know what index the kernel gives. We are
virtualized in many ways anyway. If applications want to know how many
file IDs have been allocated already, IMHO they could get the same result
by following allocations via O(1) counters, to drive low/high watermark
mechanizms (Apache).
the only real reason: scripts see the index 'directly', but as far as i've
checked, 99% of this is restricted to 1> and 2>.
what about doing the proposed 'API split', ie. giving unscalable, rigid,
slow file handles to 'old code', and give fast/scalable file IDs to 'smart
code'. It's an API extension, but we really have a problem, dont we?
[someone brought up PIDs as an example. PIDs do not have this problem, as
David S. Miller's cool 2.1 hack has shown, we can do virtually O(1) for
PID allocation.]
-- mingo