On Sun, Jun 24, 2007 at 04:10:18PM -0400, der Mouse wrote:
> > It seems to me (and in fact I maintain a libc that does this) that
> > there are a number of system calls whose result can be known to libc
> > without bothering to talk to the kernel.  The obvious ones are
> > getpid(), getppid(), and so forth but getgroups() ought to fall into
> > this category too after the first call, and barring any use of
> > certain intermediate syscalls.
> 
> getppid actually does not qualify, since the parent can die, and the
> ppid thus change to 1, without libc having a chance to notice.

Well, this can be handled with an appropriate kevent and some kernel magic
-- though I would not necessarily advocate that for NetBSD's libc.

> > This would cause problems for applications that mixed hand-coded
> > syscalls and libc, but I'm not so sure I care,
> 
> Why not?  Do you have reason to think nobody is doing that?  (Not
> having reason to think anybody is is not the same as having reason to
> think nobody is.)

I'm not sure I care because if you do things behind the C runtime's back,
you're in the realm of implementation-defined behavior and _that_ is your
own lookout.

> Furthermore, you don't mention any reason to think that the calls that
> can be optimized this way are used heavily enough to make it worth the
> bother - and potential compatability issues - of doing so.  Do you have
> such a reason?

Indeed, I do.  This optimization for getpid() alone yields hundreds of
transactions per second of improvement on the primary benchmark for my
application, all because of avoided context switches into the kernel and
back.  It also yields a measurable improvement in system build times since
the build framework is a fairly heavy getpid() user.  That's valuable enough
to me to maintain it in my libc at work; whether it is valuable enough to
NetBSD, I don't know.

Thor