Date: Wed, 7 Oct 2009 10:45:59 +0200 From: Hans Petter Selasky <hselasky@freebsd.org> To: freebsd-current@freebsd.org Cc: arch@freebsd.org, Roman Divacky <rdivacky@freebsd.org>, "Robert N. M. Watson" <rwatson@freebsd.org> Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f Message-ID: <200910071046.01595.hselasky@freebsd.org> In-Reply-To: <20091006204152.GA37998@freebsd.org> References: <alpine.BSF.2.00.0909271126590.70406@fledge.watson.org> <AEEBEAA3-6218-432D-9716-56B0CB84F9E9@freebsd.org> <20091006204152.GA37998@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910071046.01595.hselasky>