From owner-freebsd-current@FreeBSD.ORG Wed Oct 7 08:45:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F8B106566B; Wed, 7 Oct 2009 08:45:17 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 09A008FC12; Wed, 7 Oct 2009 08:45:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=1xjITpaIZIUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Yv4Q5gvs8gH1Cj39_C4A:9 a=MF4zQ8768sM9FJsRIb8A:7 a=YmpKpVShKCXwlsegRQIqdXDgRtgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1309087748; Wed, 07 Oct 2009 10:45:13 +0200 Received-SPF: softfail receiver=mailfe06.swip.net; client-ip=188.126.201.140; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 7 Oct 2009 10:45:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20091006204152.GA37998@freebsd.org> In-Reply-To: <20091006204152.GA37998@freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910071046.01595.hselasky@freebsd.org> Cc: arch@freebsd.org, Roman Divacky , "Robert N. M. Watson" Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 08:45:17 -0000 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