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
