[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: file descriptors



Selected details:

Howard Chu writes:
> Also this discussion is only meaningful on Unix systems with
> traditional select(). (E.g., winsock select() doesn't care.)

OK, that probably takes care of a lot of my concerns.

>>>     close(slap_max_fd--);
>>>     openlog(...);
>>
>> There is hopefully some minimum number of descriptors available to any
>> process, but if you exceed that: Are you sure the number of descriptors
>> available to a process is static during this code, so that close()
>> immediately makes a descriptor available to it - instead of e.g. making
>> a descriptor available to the system, so any process could use it up?
>
> File descriptors are strictly a per-process resource. Files may be a
> system-wide resource, but since dup() only increments a reference count
> on an open file, the total number of file resources in the system isn't
> changing.

Correction - with "available descriptors" I meant the opposite:-(
Available slots which can hold a descriptor, or whatever one calls it.

>> Would it help to more generally try to get different types of
>> descriptors to cluster together?  E.g. could select() or an #ifdef in
>> slapd skip zero bytes in an fd_set, so it would handle the fd_set with
>> bytes (00, ff) faster than (55, 55)?
>
> I don't believe there's any way to maintain this kind of clustering.
> Data connections come and go, and we enable/disable selecting on them
> continually.

Well, that's the same whether the database descriptors & co are at the
top or elsewhere, so for this case having the database descriptors at
the beginning - or at #32 or whatever - would be OK.  But I dont know if
there is any point to such a variant.

> At best we could reserve the first 8 descriptors so that
> that byte is always zero.

-- 
Hallvard