Getting the current thread ID without a syscall?

[Julian Elischer]

On 1/15/13 4:03 PM, Trent Nelson wrote:
> 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.)

TLS?

>
>          Trent.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>