Re: Problem with zeroconf daemonization

On Mon, Jan 18, 2010 at 4:31 PM, Benjamin R. Haskell <[email protected]>wrote:

> [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
>
>
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:
> > >
> > >
> 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.
>
>
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
except_fds[]).


>
> > 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.

cu

__
distcc mailing list            http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc