[Bug 3049] ssh startup time on OSX is linear to _SC_OPEN_MAX

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3049

--- Comment #6 from likan_999.student at sina.com ---
Comment on attachment 3307
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3307
attempt #2

Online 129, you miss a semicolon after return, which makes it fail to
compile.

Also, we need to have "got < need" instead of "got <= need". Firstly,
got == need means the buffer given to proc_pidinfo is full, so it is
possible there are more file descriptors added, thus we need to retry
in this case. Secondly, proc_pidinfo, if given NULL buffer, will return
20 more entries than the actual file table size, so in normal cases,
the 'got < need' code path will be executed.

In case got == need, ideally we should close file descriptors in the
buffer returned, before we retry. In this way, the next retry will have
far less number of elements to work on. Otherwise, if another thread
keep adding new file descriptors, the next retry will have more file
descriptors than previous retry, causing the proc_pidinfo syscall as
well as malloc to be even slower, making it even lower chance that
there is no file table changed between two proc_pidinfo syscalls.

Again, I'd like to ask, in which case this closefrom is called while
another thread is opening new file descriptors? The retry logic is
complicated now, do we really need to introduce such a complicated
logic to handle such a corner case? My understanding is, neither
F_CLOSEM nor fallback implementation guarantees anything if there is
another thread keep opening new file descriptors, therefore this
closefrom is just on best effort basis.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.