Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f
- From: Hans Petter Selasky <hselasky@xxxxxxxxxxx>
- Date: Wed, 7 Oct 2009 10:45:59 +0200
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- References:
- Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f
- From: Robert N. M. Watson
- Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f
- From: Roman Divacky
- Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f
- Prev by Date: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD
- Next by Date: PIE support
- Previous by thread: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f
- Next by thread: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD
- Index(es):
Relevant Pages
|
