[SCM] Samba Shared Repository - branch master updated -release-4-0-0alpha6-1111-g8d63c59

[Andrew Bartlett]

On Tue, 2009-02-24 at 16:13 -0800, Steven Danneman wrote:
> > -----Original Message-----
> > From: Andrew Bartlett [mailto:abartlet at samba.org]
> > Sent: Monday, February 23, 2009 9:33 PM
> > To: samba-technical at lists.samba.org
> > Cc: Steven Danneman
> > Subject: Re: [SCM] Samba Shared Repository - branch master updated -
> > release-4-0-0alpha6-1111-g8d63c59
> > 
> > On Mon, 2009-02-23 at 23:16 -0600, Steven Danneman wrote:
> > > The branch, master has been updated
> > >        via  8d63c596a0f512c96f5663c0a9bd49d3c98c6df9 (commit)
> > >       from  3a1b4c00eb96634229fb730e9b38e8df5180756a (commit)
> > >
> > > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> > >
> > >
> > > - Log
> > > -----------------------------------------------------------------
> > > commit 8d63c596a0f512c96f5663c0a9bd49d3c98c6df9
> > > Author: Steven Danneman <steven.danneman at isilon.com>
> > > Date:   Mon Feb 23 20:46:11 2009 -0800
> > >
> > >     Refactored sys_fork() and sys_pid() into shared util library
> > >
> > >     This fixes a bug in 116ce19b, where we didn't clear the pid
> cache
> > in
> > >     become_daemon() and thus the /var/run/smbd.pid didn't match the
> > actual
> > >     pid of the parent process.
> > >
> > >     Currently S4 will clear the pid cache on fork but doesn't yet
> > take
> > >     advantage of the pid cache by using sys_pid() instead of the
> > direct
> > >     get_pid().
> > 
> > I realise these questions predate your time, but I think we should
> > answer:
> > 
> > Why do we have a PID cache? (It seems it has caused more trouble then
> > it's worth.)
> > 
> > What operating systems have such a slow getpid() that this complexity
> > is worth it?
> 
> Good question Andrew.  I don't know the answer :)  Though, there really
> isn't much complexity added since we're just storing a single int in a
> static variable per process.  So if there is a performance speedup I'd
> say the minor annoyance of creating a bug here or there is still worth
> it.

I really think that we should revert that premise, because it creates
all sorts of little hacks that 'we think help'.  Instead, unless someone
can prove this is actually a win, then we should remove it, avoid yet
another static variable and bugs that *will* again occur when fork() is
called directly. 

The only other option is to insert madding macros to ensure nobody ever
calls fork(), which would be overkill for this non-problem. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090225/61e13d1b/attachment.bin