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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
