[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