lkml.org 
[lkml]   [1997]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.044 / U:1.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site