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

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