2011/2/18 dexen deVries <dexen.devr...@gmail.com>: > 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? @_@
Benchmark utilities to measure the overhead of syscalls. It's cheating to do for getpid, but for other things like gettimeofday, it's *extremely* nice. Linux's gettimeofday(2) beats the socks off of the rest of the time implementations. About the only faster thing is to get CPU speed and use rdtsc. Certainly no other OS allows you to get the timestamp faster with a syscall. > > 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? I know we're fond of bashing people who need to eek performance out of systems, and a lot of time it's all in good fun. There's little justification for getpid, but getpid isn't the only implementor of this functionality. For other interfaces, it definitely makes sense to speed up the system to speed up applications. Argue about it all you want, but without this sort of mentality, we also wouldn't have non-blocking I/O or kernel thread support. Yes, processors are fast enough. Except when they aren't. --dho
