[libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f

[Robert Watson]

Dear all--

Those of you at the Cambridge devsummit are already aware of the port of
Apple's Grand Central Dispatch (GCD), a.k.a. libdispatch, to FreeBSD by Stacey
Son and I, in collaboration with Apple.  I've now uploaded my GCD talk slides
to the wiki:

    http://wiki.freebsd.org/200909DevSummit

We now have a devel/libdispatch port, which works out-of-the-box on FreeBSD
9-CURRENT.  libdispatch requires modest changes to kqueue, which we will merge
to 8.x once the code freeze lifts.

As of yesterday, I have libdispatch working with Apple's "Blocks" C languae
extension as found in clang, the last major architecture component required to
use GCD-based applications FreeBSD.  Jordan Hubbard at Apple has kindly
provided the necessary bits bundled up in a clang/llvm/compiler-rt package for
FreeBSD until the clang port is updated.  Some details in the attached e-mail.

As I mentioned at the FreeBSD developer summit, this is a work-in-progress (in
particular, we don't support pthread work queues, which allow the kernel
schedule to get involved in expanding the size of the thread worker pool
dynamically), but it should now be more than adequate to use in practice.

Robert N M Watson
Computer Laboratory
University of Cambridge

---------- Forwarded message ----------
Date: Sat, 26 Sep 2009 20:37:51 +0100 (BST)
From: Robert Watson <robert@...>
To: libdispatch-dev@...
Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD


Dear all:

This is a quick update for those interested in the general portability of
libdispatch, and perhaps specifically FreeBSD.

With a bit of help from Jordan Hubbard, I now have libdispatch working with
Blocks on FreeBSD.  Jordan has put up a FreeBSD clang-devel package that
includes Blocks parts and the C runtime bits here:

   http://static.macosforge.org/libdispatch/downloads/clang-devel.tgz

I've updated the libdispatch build parts to detect and use Blocks when compiled
with clang, and fixed a few nits in libdispatch that I ran into along the way
(and one apparent clang bug).  With Jordan's package as a starting point,
Blocks pretty much "just worked", so I'm optimistic that people will be able to
reproduce this on other platforms able to run the non-Blocks libdispatch
without much difficulty.

If you update to at least r45 of libdispatch, you should now be able to do:

   CC=clang ./configure --with-blocks-runtime=/usr/local/lib

and get a libdispatch with Blocks support.

The reason for the configure argument is that the current clang-devel package
doesn't automatically add libBlocksRuntime dependency for binaries compiled
with -fblocks.  Once Blocks support shakes out a bit more in clang/FreeBSD,
this should go away.

I am able to run basic Blocks-based test tools with GCD on FreeBSD without
difficulty.  The FreeBSD port should be updated to reflect this shortly.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
libdispatch-dev mailing list
libdispatch-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Hans Petter Selasky-2]

Hi,

Can the Apple's "Blocks" C language extension be used when programming in the
kernel? Or is this a user-space only feature?

--HPS

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Chuck Swiger-2]

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.

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

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Robert Watson]

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
>

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Steve Kargl]

On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote:

>
> 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.
>

It is unlikely that gcc will grow support for block any time soon.

http://gcc.gnu.org/ml/gcc/2009-09/msg00272.html

--
Steve
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Roman Divacky]

On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote:

>
> 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.

apple-gcc can do blocks iirc not that it matters for us. judging from the
discussion on gcc ML they dont like this feature (they prefer C++0x lambdas
and the thing from the new C standard iirc)
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Chuck Swiger-2]

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/

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

[Hans Petter Selasky-2]

On Tuesday 06 October 2009 22:41:52 Roman Divacky wrote:

> On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote:
> > 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

Hi Robert,

I would argue that it is highly desirable to be able to pre-allocate memory
for the given "callbacks" [here: Apple's "Blocks"]. Apple's "Blocks" reminds
me of the USB stack's "msignal" system. "msignal" associates a piece of code
with some data structure, and executes it for callback.

Memory allocation is always a challenge. To allocate memory on the fly can
also be a performance issue, and not at least make problems for realtime
systems.

I would suggest that the language is extended so that the elements that gets
allocated are in the form of a structure.

Example pseudo code:

struct async_callback_001 {
        struct libdispatch_data xxx;
        int x;
        int y;
};

void
my_func(int x, int y)
{
   static struct queue pq;
   static struct async_callback_001 data;

   init_queue(&pq);

        queue(&pq, &data, ^{
                block of code which can only access parent fields
       that are given through the "data" structure.
        });
}

Also there should be the possibility to lock the queue and test if an instance
of a Apple Block has been queued for execution, because it is not just about
paralell execution, but also about being able to drain/stop a system without
polling.

I admit I haven't looked too closely at the Apple Block's system yet, so maybe
some of the features I'm asking for are already present.

> > -- 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.

Maybe that suggests that malloc() is the wrong way forward for keeping the
temporary variable storage. Like I state in my example above, maybe the
temporary variable storage should be separated out, so that for instance in a
critical context, pre-allocated or static memory can be used instead?!

> > Also,
> > blocks are currently specific to clang, although with any luck gcc
> > will grow them also.

--HPS

_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."