From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 15:09:27 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A3461065673 for ; Tue, 20 Dec 2011 15:09:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 09BFA8FC14 for ; Tue, 20 Dec 2011 15:09:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 807CF46B0D; Tue, 20 Dec 2011 10:09:26 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 10F98B91A; Tue, 20 Dec 2011 10:09:26 -0500 (EST) From: John Baldwin To: freebsd-threads@freebsd.org Date: Tue, 20 Dec 2011 10:09:25 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> In-Reply-To: <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201112201009.25534.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 10:09:26 -0500 (EST) Cc: Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:09:27 -0000 On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote: > On 20 Dec 2011 at 8:22, John Baldwin wrote: >=20 > > > Everything is the way it is for a good reason. If it doesn't make=20 > > > sense to you that's most likely because you're not half as=20 > > > experienced or clever as you think you are. If you really want to=20 > > > know why something is the way it is, all discussion regarding all=20 > > > points is documented in full. > >=20 > > Mmmm, you might be well served to check up on the experience of some of > > the folks you are conversing with. Otherwise you risk reducing your > > credibility in the present forum. Also, to argue that "everything" in > > a standard is perfect is, eh, a bit of a stretch. There's a reason for > > the connotation associated with the phrase "design by committee". >=20 > That's not what I said John, and I object to you saying that I did. I=20 > said, very specifically, that everything is the way it is for a good=20 > reason. I did not at any stage suggest it was perfect, or right, or=20 > even wise. =46air enough, but I'm not sure I would agree with your definition of "good= "=20 reasons. > > > > Why are fundamentally and necessary programming tools, such as a > > > > "assert this mutex is held" missing ? > > >=20 > > > I think that was rejected due to concerns about introducing race=20 > > > conditions if I remember correctly. You'll generally find there is no= =20 > > > easy way of checking the state of anything threading related for the= =20 > > > same reason. > >=20 > > Err, no, there should be no races here. >=20 > Sorry, I meant race conditions in the way a typical end user=20 > programmer might naively choose to use it. A lot of APIs were dropped=20 > or modified to help inhibit the damage from na=EFve use. Humm. I fail to see how a user can misuse an assert() in a way that creates a race condition. An assert(), by it's nature, should have no program visi= ble changes. If the programmer puts the assertion in the wrong place then it may very well lead to false positives, but that is true of any assertion. I can understand why you may not want users to use the equivalent of an 'islocked' function (I'm not a big fan of those myself), but an assertion is weaker than an 'islocked' function. We could look at adding an _np extension. However, I expect that in practi= ce nothing is going to use this API for a long while (if ever). On POSIX syst= ems pthreads is going to be more portable and there is a lot of code already=20 written to pthreads. > I might add there is absolutely no reason why implementations can't=20 > add _np extensions. The spec might even add them in a later TR if=20 > they prove common enough. For example, I'd like thread_timedjoin() in=20 > there, but I'll have to get Austin to sign off on pthread_timedjoin()=20 > first. I agree this would be a useful extension. What I would actually like in=20 =46reeBSD-land (and I'm not sure if Apple's libdispatch already does this=20 internally) is to be able to add a kevent() for a thread and have it fire w= hen=20 the thread exits. This would be similar to how a thread in NT becomes=20 signalled when it exits. =2D-=20 John Baldwin