Messages in this thread | | | Date | Wed, 26 Nov 1997 15:38:54 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: file ID redesign proposal |
| |
Jeremy, thanks for your comments,
On Wed, 26 Nov 1997, Jeremy Fitzhardinge wrote:
> Lots of programs are perfectly in their rights to expect the traditional > "next free fd" behaviour. The most troublesome will be the shells: not > only do they themselves use it, they pass on that behaviour to shell > scripts. I'd expect that any program which uses mildly complex fd > manipulation takes advantage of this behaviour. > > The idiom which is most likely to break is > > close_all(); > open("/dev/ttyX", O_RDWR); > dup(); > dup();
this is the 1) workaround for ID 0,1,2. Question is, does code expect it for 3,4,5.... too?
> A newly execd program could reasonably expect this to work: > > int main() > { > int fd = dup(2); > assert(fd == 3); > ...
new processes get forward-IDs, and LIFO (or FIFO) when reusing IDs, so i expect the above case to work out of box. What breaks are such cases:
open(); open(); close(x); open(); close(y);
fd = dup(2); assert(fd == 3);
so the real breakage is: applications cannot expect to get first-free ID >= 3 when _reusing_ file IDs. Eg. an application allocates all files from 0 to 100, then frees 97, 51 and 77, and expects the next open() to give ID 51.
-- mingo
| |