sys_fork() / sys_getpid()

[simo]

On Sat, 2012-03-24 at 07:11 -0700, Jeremy Allison wrote: 
> On Sat, Mar 24, 2012 at 02:58:19PM +0100, Volker Lendecke wrote:
> > On Sat, Mar 24, 2012 at 02:43:15PM +0100, Jelmer Vernooij wrote:
> > > At the moment we have two trivial wrappers for fork() and getpid() in
> > > lib/util/system.c. These wrappers exist so that we can cache the PID and
> > > avoid a system call when getpid() is called.
> > > 
> > > Is this optimization actually still worth the trouble these days? We
> > > don't seem to have any regularly called code paths that need it. The
> > > printing code seems to use it as a simple way of identifying a single
> > > server in the database, but that can be worked around by just using a
> > > single variable there.
> > > 
> > > Furthermore, there is the risk that we end up not updating the pid after
> > > a fork() - thus ending up with sys_getpid() returning the wrong pid. For
> > > example, our libraries are used in various applications, either directly
> > > or as part of e.g. openchange, which don't use sys_fork() but plain fork.
> > > 
> > > Thoughts?

I suffered this problem while I was working on the prefork code for
spoolssd and lsasd, I couldn't understand why some code was buggy, until
I found out it was using sys_getpid() and I was not using sys_fork().

> > I think that can go. I think at least glibc caches that
> > anyway, and we try to move away from getpid to
> > messaging_server_id() and friends.
> 
> +1 from me also (and I added them originally :-).
> 
> No longer needed - thanks !

Yeah the less "special calls" we have the better, they generally only
get in the way because of this kind of unexpected side effects, when
mixing code.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>