From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 16:50:55 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D40106567C; Tue, 16 Sep 2008 16:50:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id ABEEE8FC08; Tue, 16 Sep 2008 16:50:54 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m8GGortX011704; Tue, 16 Sep 2008 12:50:53 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 16 Sep 2008 12:50:53 -0400 (EDT) Date: Tue, 16 Sep 2008 12:50:53 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andrey Chernov In-Reply-To: <20080916160535.GA40676@nagual.pp.ru> Message-ID: References: <20080916140319.GA34447@nagual.pp.ru> <20080916144502.GA39765@nagual.pp.ru> <3bbf2fe10809160753o7e5e8a78q7c6bd44c02bfd5c2@mail.gmail.com> <20080916150120.GA40087@nagual.pp.ru> <20080916160535.GA40676@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , current@freebsd.org Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2008 16:50:55 -0000 [ Trimmed ] On Tue, 16 Sep 2008, Andrey Chernov wrote: > On Tue, Sep 16, 2008 at 11:36:03AM -0400, Daniel Eischen wrote: > >> Well, you could speed up getpid() by having libc wrap all fork() >> variants. The idea is that getpid() would only call __sys_getpid() >> the first time it was called and then only after a fork(). It >> would return the saved process id for all other cases. > > Yes, speeding up getpid() by caching its pid is nice idea. > But I am completely unaware how to create syscall wrappers inside libc. :( > I think about something like that: > > __weak_reference(_fork, fork); I think you'll have to implement it as __fork() in libc, with _fork and fork both being weak references to __fork() in libc. The thread libraries will have to call __fork() instead of __sys_fork() by implementing "fork" as _fork() and providing a weak reference from fork to _fork. You can see wait() as an example. Probably rfork() and vfork() will need to be handled as well, though I don't think that the thread libraries care about these. > But how it will coexists with the same __weak in thread/thr_fork.c ? > Are some threading locks required in this code? I think you can do it without locks. After a fork() you are single threaded so you can easily set/clear __cur_thread. Otherwise, the worst case is that multiple threads will call _sys_getpid() simultaneously the first time, but as long as you atomically update __cur_thread, it won't matter - each thread will have retrieved the same exact process id so it is okay if they all update __cur_thread. pid_t __getpid(void) { if (__cur_thread != -1) return (__cur_thread); atomic_set_32(&__cur_thread, __sys_getpid()); return (__cur_thread); } __weak_reference(__getpid, getpid); __weak_reference(__getpid, _getpid); Or something like that... -- DE