[libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD

[Chuck Swiger]

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/