From owner-freebsd-current@FreeBSD.ORG Tue Oct 6 20:29:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CD11065672; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C15648FC28; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) Received: from [192.168.2.101] (host81-155-13-237.range81-155.btcentralplus.com [81.155.13.237]) by cyrus.watson.org (Postfix) with ESMTPSA id 8AE7C46B35; Tue, 6 Oct 2009 16:29:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Date: Tue, 6 Oct 2009 21:29:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> To: Chuck Swiger X-Mailer: Apple Mail (2.1076) Cc: arch@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:29:55 -0000 On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > Hi, Hans-- > > On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: >> Can the Apple's "Blocks" C language extension be used when >> programming in the kernel? Or is this a user-space only feature? > > While the main benefit of blocks is in conjunction with libdispatch > for userland apps, they can be used by themselves, in the kernel or > elsewhere. When a block is instantiated (perhaps not the formal terminology), the blocks runtime allocates memory to hold copies of relevant variables from the calling scope. This memory allocation may present an issue in some calling contexts in the kernel -- in particular, it won't be appropriate in contexts were non-sleepable locks are held, interrupt threads, etc. While it should be possible to use the primitive in the kernel, we may want to think carefully about these implications. Also, blocks are currently specific to clang, although with any luck gcc will grow them also. Robert > > A block is a closure and starts off living on the stack (although, a > block can outlive the stack frame of the caller by being copied over > to the heap if needed); the compiler wraps automatic variables which > were around in the scope of the caller, turns their type into const > (unless you explicitly declare that you need to change a variable by > using __block storage keyword, in which case that variable is kept > on the heap and accessed by reference) in order to preserve the > state until the block runs. > > In effect, blocks are normal function invocations which also have an > extra argument which is the context or pointer to the saved > environment state. They can be used to implement callbacks and > continuations in a clean way, although you do have some overhead > with accessing mutable variables via pointer dereference to the > struct holding your saved context. However, most uses of callbacks > in C are implemented as functions which accept a void *, which is > used to feed the callback function a struct * of some sort, so the > end result is fairly similar. > > Regards, > -- > -Chuck >