[self-reply] On Mon, 18 Jan 2010, Benjamin R. Haskell wrote:
> On Mon, 18 Jan 2010, Lennart Poettering wrote: > > > Uh, hardcoding the 1024 is not a good idea. And always looping up to > > RLIMIT_NOFILE or _SC_OPEN_MAX is actually kinda slow. Looping > > through /proc/self/fd/ should be the fastest way to close all those > > fds. > > Yeah, sorry all, should've added <sarcasm> tags w/ actually-using > 1024. That said, it's not clear what the best alternative is. Pretty good discussion of alternatives+caveats at: http://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor#answer-918469 > [...] > > How universal is /proc/self/fd/? > See part of above link -- seems AIX is the main holdout, plus /dev/fd/ on FreeBSD and derivatives [Darwin is FreeBSD-derived, right?]. > > Might be an idea to simply copy this function: > > > > http://git.0pointer.de/?p=libdaemon.git;a=blob;f=libdaemon/dfork.c;h=70fce862894ba16d66127d10547799aaa045fad4;hb=refs/heads/master#l485 > > Sure, modulo portability of /proc/self/fd/. Or is the Avahi stuff the > limiting factor in portability anyway? (no slight intended -- just > curious -- it would surprise me if it were) Seems like the right path, given the '/proc/[pid]/fd/' and '/dev/fd/' caveats mentioned at the link. > Either way, though, there seems to be agreement that this is a 'distcc' > problem and not a 'paludis' problem? [still interested in the consensus here] Best, Ben __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc