From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 18 Feb 2011 08:29:54 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <86ipx4s36p.fsf@cmarib.ramside> <86ei7ry76s.fsf@cmarib.ramside> <86zkqf46vz.fsf@cmarib.ramside> <86mxmfuiep.fsf_-_@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: b03b0b98-ead6-11e9-9d60-3106f5b1d025 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- - erik