Re: add closefrom() call
--Apple-Mail-1--672140753
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Jul 6, 2007, at 9:57 AM, Julian Elischer wrote:
> Robert Watson wrote:
>> On Fri, 6 Jul 2007, Julian Elischer wrote:
>>> Ed Schouten wrote:
>>>> * LI Xin <delphij@delphij.net> wrote:
>>>>> Here is my implementation for FreeBSD. Some difference between
>>>>> my and DragonFly's implementation:
>>>>>
>>>>> - closefrom(-1) would be no-op on DragonFly, my version would
>>>>> close all open files (From my understanding of OpenSolaris's
>>>>> userland implementation, this is Solaris's behavior).
>>>>> - my version closefrom(very_big_fd) would result in EBADF. I
>>>>> am not very sure whether this is correct, but it does not hurt
>>>>> for applications that thinks closefrom() would return void.
>>>>
>>>> Wouldn't it be better to just implement it through fcntl() and
>>>> implement closefrom() in libc?
>>>
>>> that's a possibility but I personally thing the huge difference
>>> in efficiency makes it worth putting it in the kernel. Quite a
>>> few programs I know of could really help their startup time with
>>> this as the first thing they do is "close the first 2000 file
>>> descriptors.
>> The Solaris implementation appears to implement two strategies:
>> (1) If procfs is mounted, list the fd directory to get a list of
>> open fds,
>> then close those by number.
>> (2) If procfs is not mounted, query the number of open fds using
>> the resource
>> limit interface, then sequentially close until the right
>> number close.
>> Hence my question as to whether there's actually a big benefit or
>> not -- do we think closefrom() is a performance-critical function?
>
>
> It's one of those things where it's so simple to do it that it
> hardly seems worth arguing about the colour, or even whether colour
> is spelled color or colour.
>
>> Robert N M Watson
>> Computer Laboratory
>> University of Cambridge
>
So guys, where can I pick up my bike-shed?
Bert JW Regeer
--Apple-Mail-1--672140753--
討論串 (同標題文章)
完整討論串 (本文為第 13 之 26 篇)：