Jamie Lokier wrote:
Gilad Ben-Yossef wrote:
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+ env->thread_id = GetCurrentProcessId();
+#else
+ env->thread_id = getpid();
+#endif
*penv = env;
hmm... maybe I'm missing something, but in Linux at least I think you
would prefer this to be gettid() rather then getpid as each CPU has it's
own thread, not a different process.
On most platforms, getpid() returns the same value for all threads, so
it's not useful as a thread id.
Of course it does - this what POSIX says it should do (Linux 2.4 in
compliance not withstanding). Which is why I suggested to use on Linux
the non standard gettid() rather then getpid
On Linux, it depends which version of threads. The old package,
LinuxThreads, has different getpid() for each thread. The current one,
NPTL, has them all the same.
LinuxThreads behavior is wrong according to the POSIX standard. Of
course, nothing else was possible with 2.4 kernels, so this is not an
error on LinuxThreads coders part.
What you're supposed to do with pthreads in general is use pthread_self().
Unfortunately, AFAIK the opaque handle that pthread_self() returns is
not quite meaningless outside of the process whereas what the non
standard gettid() returns can actually be used to identify a thread from
"outside" the process, like the shell.
Gilad
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Chief Coffee Drinker
Codefidence Ltd. | Web: http://codefidence.com
Work: +972-3-7515563 ext. 201 | Mobile: +972-52-8260388
"Your hovercraft is full of eels. For information on
emptying your hovercraft, turn to Section 2.6.a.17
of your hovercraft user manual".
- The Monty Python technical writer