On Mon, 18 Jan 2010, Lennart Poettering wrote: > On Mon, 18.01.10 01:10, Benjamin R. Haskell (dis...@benizi.com) wrote: > > > If so, it seems like a pretty easy fix (to just close more fd's than > > 0, 1, and 2). I can commit the attached patch if 1024 doesn't seem > > too magic-number-y (and I'm not spouting nonsense). > > 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. In some one-off thing I wrote I used: #include <linux/limits.h> for (fd = 0; fd < NR_OPEN; fd++) close(fd); But, obviously that's Linux-specific. And as Lennart points out, it can be slow. (didn't notice w/ what I used it for) How universal is /proc/self/fd/? > 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) Either way, though, there seems to be agreement that this is a 'distcc' problem and not a 'paludis' problem? Best, Ben __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc