From owner-freebsd-arch@FreeBSD.ORG  Wed Oct 31 15:58:09 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 61E6E16A421;
	Wed, 31 Oct 2007 15:58:09 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60])
	by mx1.freebsd.org (Postfix) with ESMTP id 367E313C49D;
	Wed, 31 Oct 2007 15:58:09 +0000 (UTC)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1])
	by mail.bitblocks.com (Postfix) with ESMTP id 4395A5B59;
	Wed, 31 Oct 2007 08:32:48 -0700 (PDT)
To: Alfred Perlstein <alfred@freebsd.org>
In-reply-to: Your message of "Tue, 30 Oct 2007 13:12:29 PDT."
	<20071030201229.GA33488@elvis.mu.org> 
Date: Wed, 31 Oct 2007 08:32:48 -0700
From: Bakul Shah <bakul@bitblocks.com>
Message-Id: <20071031153248.4395A5B59@mail.bitblocks.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Garance A Drosehn <gad@FreeBSD.org>,
	freebsd-arch@FreeBSD.org
Subject: Re: C++ in the kernel 
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2007 15:58:09 -0000

> > > >     critical_section(lock) {
> > > > 	...
> > > > 	bar:
> > > > 	...
> > > > 	if (cond1) break;
> > > > 	...
> > > > 	if (cond2) goto foo;
> > > > 	...
> > > > 	if (cond3) goto bar;
> > > > 	...
> > > > 	if (cond4) return; // from enclosing function
> > > > 	...
> > > >     }
> > > >     ...
> > > >     foo:
> > > 
> > > 
> > > do you mean like C++:
> > > 
> > > do {
> > > 	critical_object critical_instance();
> > > 
> > > 
> > > 
> > > 
> > > }
> > 
> > No idea but I can not see how that will do what I had in mind. A purely
> > lexical translation of the snippet I gave above would be something like:
> 
> You can create an object on the stack that locks the mutex given
> to it  like so:
> 
> do {
> 	mtx_lock_object mtx_locker(&lock);
> 
> }
> 
> When the object is destroyed by stack popping, the lock will be freed.
> 
> It's the same thing.

Yes indeed, thanks!  I am starting to forget all the C++
tricks I learned.  Mercifully.  Two points though. This was
an example of what is possible with macros that can inspect
their argument code + they can also do many other things that
don't fit so easily with C++'s initialization/finalization
trick.  For example what if you can't gain the lock and want
to do something else?  Two, while C++ gives you a way to
solve this problem, it does it in a "clever" way, not an
obvious way.

But I will acknowledge I am comparing vaporware with
something that works now!