[libdispatch-dev] [PATCH] Support for the GNUstep Objective-C/Blocks runtime

Niels Grewe niels.grewe at halbordnung.de
Tue Mar 13 23:48:23 PDT 2012

Hi Mark,

On Tue, Mar 13, 2012 at 11:46:39PM -0400, Mark Heily wrote:
> While I am glad to hear you are working on getting blocks support added to
> GNUstep, I am not sure it makes sense to have a completely different blocks
> runtime for Objective-C v.s. ordinary C.  Judging by the headers in libobjc2,
> it looks like you reimplemented the blocks runtime rather than copying it
> verbatim from compiler-rt. That has me somewhat worried about possible
> differences and incompatibilities, and I would prefer to use the "official"
> blocks runtime if possible.

First of all: We don't expect people to use different runtimes for C and
Objective-C programmes. C programmes will work just fine with libobjc2
as the blocks runtime (without the need to link the Objective-C
Foundation library and all), as libdispatch clearly demonstrates.

Furthermore, I don't think that GNUstep having its own implementation of
the blocks runtime is a real issue. After all, both the compiler-rt
blocks runtime and the GNUstep one work with blocks generated by clang.
Also, if incompatibilities did arise (which I think they won't), we
could always have a look at the specification and decide who get things
wrong ;-)

> As an alternative, I have repackaged the blocks runtime found in compiler-rt,
> and made a standalone library named libBlocksRuntime [1].  This is currently
> used for C/C++ programs that use libdispatch, and I would hope that Objective-C
> programs could also link against this library.

Well, the problem is that Blocks are first class objects in Objective-C.
The compiler-rt blocks runtime has some shims for this that the
Foundation library is required to patch up afterwards. By having blocks
support directly in the runtime, we avoid these troubles. 

I hope this clears a few things up. I've also CCed David Chisnall, the
maintainer of the GNUstep Objective-C runtime, who might have some more
insights into this.



More information about the libdispatch-dev mailing list