[distcc] Problem with zeroconf daemonization
Ihar `Philips` Filipau
thephilips at gmail.com
Mon Jan 18 09:04:48 MST 2010
On Mon, Jan 18, 2010 at 4:31 PM, Benjamin R. Haskell <distcc at benizi.com>wrote:
> 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:
Well, you can't satisfy all.
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.
Most fool-proof solution wins.
> > [...]
> > 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:
> > >
> > >
> > 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.
The /proc/*/fd trick is applied only to Linux platform.
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
> > 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]
IMO. Implement fool-prof generic method. Add /proc/*/fd trick for Linux (as
most commonly used platform).
Code from Lennart's hint satisfies most of the requirements.
closefrom() syscall: let somebody else who has access to the supporting
platform add a new define and code path for it. Ditto /dev/fd.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the distcc