Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu

[Jamie Lokier]

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