On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: > so this is a complete waste of time if forks > getpids. > and THREAD_GETMEM must allocate memory. so > the first call isn't exactly cheep. aren't they optimizing > for bad programming? > > not only that, ... from getpid(2) > > NOTES > Since glibc version 2.3.4, the glibc wrapper function for > getpid() caches PIDs, so as to avoid additional system calls when a > process calls getpid() repeatedly. Normally this caching is invisible, > but its correct operation relies on support in the wrapper > functions for fork(2), vfork(2), and clone(2): if an application bypasses > the glibc wrappers for these system calls by using syscall(2), then a > call to getpid() in the child will return the wrong value (to be > precise: it will return the PID of the parent process). See also > clone(2) for dis-
which boggles my mind: why would getpid() need to be optimized for in the first place? Konqueror 4.5.5 (browser) calls it once per short session (few tabs) Firefox 4 (browser) calls it about once per tab openssh calls it once or twice per session bash calls it once lsof, find do not call it at all. what does call getpid() often? @_@ anyway, it looks a bit like library lock-in to me: ``your app better perform _every_ syscall through glibc, or else'' -- or else strange things may happen, eh? -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90
