<div class="gmail_quote">On Mon, Jan 18, 2010 at 4:31 PM, Benjamin R. Haskell <span dir="ltr"><<a href="mailto:distcc@benizi.com">distcc@benizi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[self-reply]<br>
<div class="im"><br>
On Mon, 18 Jan 2010, Benjamin R. Haskell wrote:<br>
<br>
> On Mon, 18 Jan 2010, Lennart Poettering wrote:<br>
><br>
</div><div class="im">> > Uh, hardcoding the 1024 is not a good idea. And always looping up to<br>
> > RLIMIT_NOFILE or _SC_OPEN_MAX is actually kinda slow. Looping<br>
> > through /proc/self/fd/ should be the fastest way to close all those<br>
> > fds.<br>
><br>
> Yeah, sorry all, should've added <sarcasm> tags w/ actually-using<br>
> 1024. That said, it's not clear what the best alternative is.<br>
<br>
</div>Pretty good discussion of alternatives+caveats at:<br>
<br>
<a href="http://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor#answer-918469" target="_blank">http://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor#answer-918469</a><br>
<br></blockquote><div><br>Well, you can't satisfy all.<br>And the problem (in the particular case) isn't even performance critical: everything what would do the work in less than half second is OK.<br>Most fool-proof solution wins.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> [...]<br>
<div class="im">><br>
> How universal is /proc/self/fd/?<br>
><br>
<br>
</div>See part of above link -- seems AIX is the main holdout, plus /dev/fd/<br>
on FreeBSD and derivatives [Darwin is FreeBSD-derived, right?].<br>
<div class="im"><br>
<br>
> > Might be an idea to simply copy this function:<br>
> ><br>
> > <a href="http://git.0pointer.de/?p=libdaemon.git;a=blob;f=libdaemon/dfork.c;h=70fce862894ba16d66127d10547799aaa045fad4;hb=refs/heads/master#l485" target="_blank">http://git.0pointer.de/?p=libdaemon.git;a=blob;f=libdaemon/dfork.c;h=70fce862894ba16d66127d10547799aaa045fad4;hb=refs/heads/master#l485</a><br>
><br>
> Sure, modulo portability of /proc/self/fd/. Or is the Avahi stuff the<br>
> limiting factor in portability anyway? (no slight intended -- just<br>
> curious -- it would surprise me if it were)<br>
<br>
</div>Seems like the right path, given the '/proc/[pid]/fd/' and '/dev/fd/'<br>
caveats mentioned at the link.<br>
<div class="im"><br></div></blockquote><div><br>The /proc/*/fd trick is applied only to Linux platform.<br>The code looks good to me. (Though as a nitpick: if they are so performance conscious, they could have used qsort/bsearch to avoid O(n^2) look-ups on except_fds[]).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
> Either way, though, there seems to be agreement that this is a 'distcc'<br>
> problem and not a 'paludis' problem?<br>
<br>
</div>[still interested in the consensus here]<br>
<div><div></div><br>
</div></blockquote></div><br>IMO. Implement fool-prof generic method. Add /proc/*/fd trick for Linux (as most commonly used platform).<br>Code from Lennart's hint satisfies most of the requirements.<br>closefrom() syscall: let somebody else who has access to the supporting platform add a new define and code path for it. Ditto /dev/fd.<br>
<br>I'm no distcc maintainer, but IMHO there is no need consensus here for a pure technical question on how to close fds. Do not plan for problem - solve the problems as they come. Especially considering that in the case they are going to be easy to solve.<br>
<br>cu<br>