Date: Tue, 15 Jan 2013 18:03:30 -0500 From: Trent Nelson <trent@snakebite.org> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Alfred Perlstein <bright@mu.org> Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115230330.GA53211@snakebite.org> In-Reply-To: <1358289221.32417.129.camel@revolution.hippie.lan> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> <50F5D82C.7070400@mu.org> <1358289221.32417.129.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote:
> On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote:
> > On 1/15/13 1:43 PM, Konstantin Belousov wrote:
> > > On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
> > >>
> > >> Luckily it's for an open source project (Python), so recompilation
> > >> isn't a big deal. (I also check the intrinsic result versus the
> > >> syscall result during startup to verify the same ID is returned,
> > >> falling back to the syscall by default.)
> > > For you, may be. For your users, it definitely will be a problem.
> > > And worse, the problem will be blamed on the operating system and not
> > > to the broken application.
> > >
> > Anything we can do to avoid this would be best.
> >
> > The reason is that we are still dealing with an "optimization" that perl
> > did, it reached inside of the opaque struct FILE to "do nasty things".
> > Now it is very difficult for us to fix "struct FILE".
> >
> > We are still paying for this years later.
> >
> > Any way we can make this a supported interface?
> >
> > -Alfred
>
> Re-reading the original question, I've got to ask why pthread_self()
> isn't the right answer? The requirement wasn't "I need to know what the
> OS calls me" it was "I need a unique ID per thread within a process."
The identity check is performed hundreds of times per second. The
overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is
negligible -- I can't say the same for a system/function call.
(I'm experimenting with an idea I had to parallelize Python such
that it can exploit all cores without impeding the performance
of normal single-threaded execution (like previous-GIL-removal
attempts and STM). It's very promising so far -- presuming we
can get the current thread ID in a couple of instructions. If
not, single-threaded performance suffers too much.)
Trent.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130115230330.GA53211>