From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 05:42:21 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 B619D106568D; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9E83A8FC16; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [17.151.125.209] by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KR400DV4QIIHV60@asmtp022.mac.com>; Tue, 06 Oct 2009 22:42:21 -0700 (PDT) Message-id: <6E3505F9-C73D-480A-9304-890BF153983E@mac.com> From: Chuck Swiger To: "Robert N. M. Watson" In-reply-to: Date: Tue, 06 Oct 2009 22:42:18 -0700 References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> X-Mailer: Apple Mail (2.936) Cc: arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD 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: Wed, 07 Oct 2009 05:42:21 -0000 Hi, Robert-- On Oct 6, 2009, at 1:29 PM, Robert N. M. Watson wrote: >> 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. Yes, you bring up some good points. Blocks haven't been around for long enough to have a widely visible track record as to their benefits and tradeoffs, and the compiler toolchain support is not too widely present, either. While I am confident that blocks could be used in the kernel (and so answered the question which Hans asked), whether the FreeBSD kernel should attempt to use them (much less right away) is more complex topic. Apple's changes to gcc-4.2 to add support for blocks is likely to be available here: http://opensource.apple.com/source/gcc/gcc-5646, or perhaps nearby in a sibling directory [1]. Blocks are normally allocated on the stack, unless you decide to copy them to the heap [2]. If do you need to put a block onto the heap, you shouldn't try to do so in a situation where you aren't OK to call malloc(9) or whatever Block_copy() would use. On the other hand, it's entirely possible that using blocks and dispatch queues would help identify and/ or resolve some of hard-to-reproduce race condition bugs or even deadlocks lurking in the depths of recursive locking/lock-order reversals. To address the other point made by Steve and Roman; the proposed C++0x lambda syntax using [] brackets conflicts with existing code written in ObjC++, so that is likely going to be a non-starter for some folks. Also, the ^ operator can't be overloaded in C++, whereas you can overload the array access operator (aka []). Regards, -- -Chuck [1]: There are a bunch of test cases under http://opensource.apple.com/source/gcc/gcc-5646/gcc/testsuite/gcc.apple/block-* , so I think I've found the right place. :-) [2]: Such as when you are returning a block, or you have a __block variable which itself is a block, or you are using C++ or ObjC and have GC or some sort of reference counting in use, as discussed here: http://clang.llvm.org/docs/BlockLanguageSpec.txt or here: http://thirdcog.eu/pwcblocks/