From mboxrd@z Thu Jan 1 00:00:00 1970 References: <201102181445.41877.dexen.devries@gmail.com> In-Reply-To: <201102181445.41877.dexen.devries@gmail.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: Cc: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> From: David Leimbach Date: Fri, 18 Feb 2011 06:54:36 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b0484cea-ead6-11e9-9d60-3106f5b1d025 Sent from my iPhone On Feb 18, 2011, at 5:45 AM, dexen deVries 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? >>=20 >> not only that, ... from getpid(2) >>=20 >> NOTES >> Since glibc version 2.3.4, the glibc wrapper function for=20 >> 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= =20 >> 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=20 >> precise: it will return the PID of the parent process). See also >> clone(2) for dis- >=20 > which boggles my mind: why would getpid() need to be optimized for in the f= irst=20 > place? LMbench? >=20 > 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. >=20 > what does call getpid() often? @_@ >=20 >=20 > anyway, it looks a bit like library lock-in to me: ``your app better perfo= rm=20 > _every_ syscall through glibc, or else'' -- or else strange things may hap= pen,=20 > eh? >=20 >=20 > --=20 > dexen deVries >=20 > [[[=E2=86=93][=E2=86=92]]] >=20 >> how does a C compiler get to be that big? what is all that code doing? >=20 > iterators, string objects, and a full set of C macros that ensure > boundary conditions and improve interfaces. >=20 > ron minnich, in response to Charles Forsyth >=20 > http://9fans.net/archive/2011/02/90 >=20