From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mi5d9-0003k3-OO
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:05:03 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mi5d4-0003gr-CL
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:05:02 -0400
Received: from [199.232.76.173] (port=53316 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mi5d4-0003gY-48
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:04:58 -0400
Received: from mail2.shareable.org ([80.68.89.115]:41000)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1Mi5d3-0006Ai-HV
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:04:57 -0400
Date: Mon, 31 Aug 2009 13:04:52 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu
Message-ID: <20090831120452.GG7129@shareable.org>
References: <1247781328-17249-1-git-send-email-glommer@redhat.com>
	<4A96BF30.7090200@siemens.com>
	<20090828011856.GE5746@mothafucka.localdomain>
	<4A973530.4040002@us.ibm.com> <20090829012227.GH8036@shareable.org>
	<20090831113518.GD30340@mothafucka.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090831113518.GD30340@mothafucka.localdomain>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Glauber Costa <glommer@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org, avi@redhat.com

Glauber Costa wrote:
> On Sat, Aug 29, 2009 at 02:22:27AM +0100, Jamie Lokier wrote:
> > Anthony Liguori wrote:
> > > Glauber Costa wrote:
> > > Since we already keep the tid in the vcpu structure, it seems to make 
> > > more sense to ask "am I this vcpu thread" by doing gettid() == env->tid 
> > > than by maintaining a new global tls variable.
> > 
> > Note that a tls variable will be much faster than gettid().  Don't
> > know if you're talking about a hot path.
> just to be sure, TLS is not supported on all our linux target hosts, right?
> 
> We can probably wrap it into a function that uses gettid on linux (or whatever
> in other platforms), and uses a TLS variable where available. (and if needed).
> 
> I can agree with anthony that although TLS is in fact faster, we might not need it.
> I doubt that anything that communicates using signals will be the hot path for anything.

I was going to say just use pthread_self()!  It's fast like TLS on all
hosts, and more portable then gettid().

But then you mentioned signals.  I'm not sure if the code in question
is inside signal handlers.

pthread_self() is not officially permitted inside a signal handler.

And indeed, gives the wrong answer with some Linuxes when
sigaltstack() is used.

But if you were going to use gettid(), that means you are only
targetting Linuxes which use NPTL threads anyway, because gettid() is
not available elsewhere.  As far as I know, pthread_self() is safe in
signal handlers on all versions of NPTL threads, and unlike gettid(),
should be fast.

-- Jamie