Sent from my iPhone
On Feb 18, 2011, at 5:45 AM, dexen deVries <dexen.devr...@gmail.com> wrote: > 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? LMbench? > > 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 >
