From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JYMtG-0008RR-0o for qemu-devel@nongnu.org; Sun, 09 Mar 2008 10:52:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JYMtF-0008Q8-Ds for qemu-devel@nongnu.org; Sun, 09 Mar 2008 10:52:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JYMtF-0008Pq-7i for qemu-devel@nongnu.org; Sun, 09 Mar 2008 10:52:41 -0400 Received: from xenbox.codefidence.com ([92.48.73.16]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JYMtE-0001lS-Ob for qemu-devel@nongnu.org; Sun, 09 Mar 2008 10:52:40 -0400 Message-ID: <47D3F9AF.2030408@codefidence.com> Date: Sun, 09 Mar 2008 16:52:31 +0200 From: Gilad Ben-Yossef MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] use a thread id variable References: <12047472711034-git-send-email-gcosta@redhat.com> <12047472772114-git-send-email-gcosta@redhat.com> <47D3AD53.6030809@codefidence.com> <20080309115826.GA8077@shareable.org> In-Reply-To: <20080309115826.GA8077@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, glommer@gmail.com, chrisw@sous-sol.org, Glauber Costa 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 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