From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <201102181445.41877.dexen.devries@gmail.com> References: <201102181445.41877.dexen.devries@gmail.com> Date: Fri, 18 Feb 2011 10:15:10 -0500 Message-ID: From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b05283fe-ead6-11e9-9d60-3106f5b1d025 2011/2/18 dexen deVries : > 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. =A0so >> the first call isn't exactly cheep. =A0aren't they optimizing >> for bad programming? >> >> not only that, ... from getpid(2) >> >> NOTES >> =A0 =A0 =A0 =A0Since glibc version 2.3.4, the =A0glibc =A0wrapper =A0fun= ction =A0for >> getpid() caches =A0PIDs, =A0so =A0as =A0to =A0avoid additional system ca= lls when a >> process calls getpid() repeatedly. =A0Normally this caching is invisible= , >> but its correct =A0operation =A0relies =A0on =A0support =A0in =A0the =A0= wrapper >> functions for fork(2), vfork(2), and clone(2): if an application bypasse= s >> the =A0glibc wrappers =A0for =A0these =A0system =A0calls by using syscal= l(2), then a >> call to getpid() in the child will return the wrong value (to =A0be >> precise: =A0it will return the PID of the parent process). =A0See 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 perf= orm > _every_ syscall through glibc, or else'' -- or else strange things may ha= ppen, > 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