From owner-freebsd-arch@FreeBSD.ORG Mon Oct 5 11:06:48 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 083531065693 for ; Mon, 5 Oct 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D0DB08FC08 for ; Mon, 5 Oct 2009 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n95B6lSt088600 for ; Mon, 5 Oct 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n95B6lsB088598 for freebsd-arch@FreeBSD.org; Mon, 5 Oct 2009 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Oct 2009 11:06:47 GMT Message-Id: <200910051106.n95B6lsB088598@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 6 19:50:25 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79249106566B; Tue, 6 Oct 2009 19:50:25 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 6332D8FC28; Tue, 6 Oct 2009 19:50:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KR3004PRWBRGK20@asmtp018.mac.com>; Tue, 06 Oct 2009 11:50:20 -0700 (PDT) Message-id: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> From: Chuck Swiger To: Hans Petter Selasky In-reply-to: <200910021440.50021.hselasky@freebsd.org> Date: Tue, 06 Oct 2009 11:50:14 -0700 References: <200910021440.50021.hselasky@freebsd.org> X-Mailer: Apple Mail (2.936) Cc: arch@freebsd.org, freebsd-current@freebsd.org, Robert Watson Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:50:25 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 6 20:29:54 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CD11065672; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C15648FC28; Tue, 6 Oct 2009 20:29:54 +0000 (UTC) Received: from [192.168.2.101] (host81-155-13-237.range81-155.btcentralplus.com [81.155.13.237]) by cyrus.watson.org (Postfix) with ESMTPSA id 8AE7C46B35; Tue, 6 Oct 2009 16:29:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Date: Tue, 6 Oct 2009 21:29:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> To: Chuck Swiger X-Mailer: Apple Mail (2.1076) Cc: arch@freebsd.org, freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:29:55 -0000 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 > From owner-freebsd-arch@FreeBSD.ORG Tue Oct 6 20:35:18 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0841065692; Tue, 6 Oct 2009 20:35:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id AB2EA8FC1C; Tue, 6 Oct 2009 20:35:18 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n96KZIjp026568; Tue, 6 Oct 2009 13:35:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n96KZIY3026567; Tue, 6 Oct 2009 13:35:18 -0700 (PDT) (envelope-from sgk) Date: Tue, 6 Oct 2009 13:35:18 -0700 From: Steve Kargl To: "Robert N. M. Watson" Message-ID: <20091006203518.GA26478@troutmask.apl.washington.edu> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Chuck Swiger , Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:35:18 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Tue Oct 6 20:42:09 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E881065670; Tue, 6 Oct 2009 20:42:09 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5A99D8FC0C; Tue, 6 Oct 2009 20:42:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 06C089CB0CF; Tue, 6 Oct 2009 22:41:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFirOaSXBlXb; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id AC59A9CB27B; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n96Kfq1B038538; Tue, 6 Oct 2009 22:41:52 +0200 (CEST) (envelope-from rdivacky) Date: Tue, 6 Oct 2009 22:41:52 +0200 From: Roman Divacky To: "Robert N. M. Watson" Message-ID: <20091006204152.GA37998@freebsd.org> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Chuck Swiger , Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:42:09 -0000 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) From owner-freebsd-arch@FreeBSD.ORG Wed Oct 7 05:42:21 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B619D106568D; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9E83A8FC16; Wed, 7 Oct 2009 05:42:21 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [17.151.125.209] by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KR400DV4QIIHV60@asmtp022.mac.com>; Tue, 06 Oct 2009 22:42:21 -0700 (PDT) Message-id: <6E3505F9-C73D-480A-9304-890BF153983E@mac.com> From: Chuck Swiger To: "Robert N. M. Watson" In-reply-to: Date: Tue, 06 Oct 2009 22:42:18 -0700 References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> X-Mailer: Apple Mail (2.936) Cc: arch@freebsd.org, freebsd-current@freebsd.org Subject: Re: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 05:42:21 -0000 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/ From owner-freebsd-arch@FreeBSD.ORG Wed Oct 7 08:45:17 2009 Return-Path: Delivered-To: arch@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-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture 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 From owner-freebsd-arch@FreeBSD.ORG Thu Oct 8 14:59:04 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD9AC1065670; Thu, 8 Oct 2009 14:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 26DE68FC0A; Thu, 8 Oct 2009 14:59:03 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n98Ex0Ir069921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n98Ex0Sv059499; Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n98Ex0nQ059498; Thu, 8 Oct 2009 17:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 8 Oct 2009 17:59:00 +0300 From: Kostik Belousov To: current@freebsd.org, arch@freebsd.org Message-ID: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p+SyGXcYc+aq/C8k" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: PIE support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 14:59:04 -0000 --p+SyGXcYc+aq/C8k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline There is a patch, that should provide more or less proper support for PIE (Position Independent Executables). Besides being desirable feature itself, this is needed to be able to execute PIE binaries, both native FreeBSD and Linux images, with sysctl security.bsd.map_at_zero=0. In particular, Samba port is affected. gdb does not work for PIE binaries, I believe this is a gdb shortcoming. Patch was reviewed by Alexander Kabaev, discussed with Bjoern A. Zeeb, who tested i386 and amd64, and tested by Boris Samorodov for Linux binaries. I am asking for general testing for the patch. Also, I would ask the architecture maintainers to look for the per-arch mapbase address selected for the PIE binaries. http://people.freebsd.org/~kib/misc/pie.5.patch --p+SyGXcYc+aq/C8k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrN/jMACgkQC3+MBN1Mb4iDzQCfUrr/kLoY+6HsM7SN5prNXhdr xMQAn0L1RMTx254+EcL0gMVhpq1nDptV =6md9 -----END PGP SIGNATURE----- --p+SyGXcYc+aq/C8k-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 8 17:02:30 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B10106568B; Thu, 8 Oct 2009 17:02:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEE58FC13; Thu, 8 Oct 2009 17:02:30 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n98H2THV008175; Thu, 8 Oct 2009 10:02:29 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n98H2Thm008171; Thu, 8 Oct 2009 10:02:29 -0700 (PDT) (envelope-from sgk) Date: Thu, 8 Oct 2009 10:02:29 -0700 From: Steve Kargl To: Kostik Belousov Message-ID: <20091008170229.GA75042@troutmask.apl.washington.edu> References: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, current@freebsd.org Subject: Re: PIE support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:02:30 -0000 On Thu, Oct 08, 2009 at 05:59:00PM +0300, Kostik Belousov wrote: > > gdb does not work for PIE binaries, I believe this is a gdb shortcoming. > gdb 7.0 was released on Oct 6th. It appears to work fine with PIE. (Yes, I know that gdb 7.0 is unlikely to appear in FreeBSD.) -- Steve From owner-freebsd-arch@FreeBSD.ORG Thu Oct 8 20:01:04 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D26C71065679; Thu, 8 Oct 2009 20:01:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 724048FC1C; Thu, 8 Oct 2009 20:01:03 +0000 (UTC) Received: from c122-107-125-150.carlnfd1.nsw.optusnet.com.au (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n98K118d028518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Oct 2009 07:01:02 +1100 Date: Fri, 9 Oct 2009 07:00:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200910020930.01228.jhb@freebsd.org> Message-ID: <20091009050808.U1531@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <200910011412.31250.jhb@freebsd.org> <20091002053705.F21979@delplex.bde.org> <200910020930.01228.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Andriy Gapon Subject: Re: Interrupt Descriptions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:01:04 -0000 On Fri, 2 Oct 2009, John Baldwin wrote: > On Thursday 01 October 2009 4:41:19 pm Bruce Evans wrote: > ... > However, all of this is still orthogonal to interrupt description strings. > >> Here is the 4.4BSD-Lite2 code for hp300: >> >> % .globl _intrcnt,_eintrcnt,_intrnames,_eintrnames >> % _intrnames: >> % .asciz "spur" >> % .asciz "hil" >> % .asciz "lev2" >> % .asciz "lev3" >> % .asciz "lev4" >> % .asciz "lev5" >> % .asciz "dma" >> % .asciz "clock" >> % .asciz "statclock" >> % .asciz "nmi" >> % _eintrnames: >> % .even >> % _intrcnt: >> % .long 0,0,0,0,0,0,0,0,0,0 >> % _eintrcnt: >> >> This takes 53 bytes (plus 1 or 3 for padding) for the string space. >> Most machines still need about 53 bytes for the string space (don't >> waste slots to count or name stray interrupts separately). These 53 >> bytes can be built and processed by userland on every sysctl much >> faster than the 32K of mostly-unused bytes can even be copied out. > > I think this mostly serves to prove the point that the existing design is > tailored to static configurations, not dynamic ones. No, string spaces are ideal for dynamic management of small collections of strings and for larger collections of strings that are accessed mostly sequentially. They are essentially the same as a text file. There is no better data structure for a text file than to concatenate all the lines together. Sometimes you want non-sequential access for text files, e.g., for tail -n and in editors, but this is rare and then you can build random-access substructures as needed. Collections of interrupt names are both small and accessed mostly sequentially. Bruce