Re: Problem with zeroconf daemonization

"Benjamin R. Haskell" <[email protected]>
Newsgroups gmane.comp.compilers.distcc
Message-ID <[email protected]>
On Mon, 18 Jan 2010, Lennart Poettering wrote:

> On Mon, 18.01.10 10:19, Benjamin R. Haskell ([email protected]) wrote:
> 
> > How universal is /proc/self/fd/?
> 
> It's Linux-only.

Not said the link I sent later...  Should I use it on those others 
listed?  (Solaris, Cygwin, NetBSD)  or even switch to /proc/[pid]/fd/ 
(to catch all of the above plus AIX).


>  
> > > 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)
> 
> Avahi works on the BSDs and Solaris too. It has even been ported to 
> MacOS.
> 
> I wouldn't bother with the other systems. Linux is the only one that 
> matters. The code I linked above is fast on Linux but still works on 
> non-Linux. That should be good enough.

Ah, yes.  I glossed over the ifdef __linux__.  Works-better on linux and 
doesn't suffer on others does sound good-enough for now.

Will send a patch for review later (I think I still have commit access 
from the last zeroconf thing I fixed, but I forget whether distcc has a 
formal 'review' process?).

The function in libdaemon accepts a list of excluded fds.  AFAICT, in 
distcc, the daemon should keep:

1. daemon lock file
2. hosts file

But, I also see a pair of fds for a pipe, and two taken up for sockets.  
I'll take a closer look later, but are those referenced some place in 
the Avahi code that'd be accessible to distcc?

-- Ben
__
distcc mailing list            http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.