[lkml]   [2007]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 7/8] fdmap v2 - implement sys_socket2
Kyle Moffett writes:

> 1) Linear FD allocation makes it IMPOSSIBLE for libraries to
> reliably use persistent FDs behind an application's back. For

That's not completely true; for example, openlog() opens a file
descriptor for the library's own use, as does sethostent(). I agree
that it creates difficulties if the library implementor wants to use a
file descriptor in a set of functions that didn't previously use one,
but with a bit of assistance from the kernel, that can be solved
without breaking the ABI.

> for (i = 0; i < NR_OPEN; i++)
> if (!fd_is_special_to_us(i))
> close(i);
> Note that this is conceptually buggy, but occurs in several major C
> programming books, most of the major shells, and a lot of other
> software to boot.

Buggy in what way? In the use of the NR_OPEN constant?

> 3) In order to allocate new FDs, the kernel has to scan over a
> (potentially very large) bitmap. A process with 100,000 fds (not
> terribly uncommon) would have 12.5kbyte of FD bitmap and would trash
> the cache every time it tried to allocate an FD.

For specialized programs like that we can offer alternative fd
allocation strategies if necessary (although I expect that with
100,000 fds other things will limit performance more than

None of those things is an excuse for breaking the ABI, however.
As I said to Davide, I was really protesting about the attitude that
we can just break the ABI however and whenever we like and force
programs to adapt.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-06-10 08:51    [W:0.143 / U:4.404 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site