From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29436 invoked by alias); 3 Nov 2004 14:33:29 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 29427 invoked from network); 3 Nov 2004 14:33:27 -0000 Received: from unknown (HELO ps10.kent.dot.net.au) (202.147.78.201) by sourceware.org with SMTP; 3 Nov 2004 14:33:27 -0000 Received: from ip-86-129.dot.net.au ([202.147.86.129] helo=ise.canberra.edu.au) by ps10.kent.dot.net.au with esmtp (Exim 3.35 #4) id 1CPMCj-0002Ai-00 for pthreads-win32@sources.redhat.com; Thu, 04 Nov 2004 01:33:41 +1100 Message-ID: <4188EC35.9080108@ise.canberra.edu.au> Date: Wed, 03 Nov 2004 14:33:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 MIME-Version: 1.0 To: pthreads-win32 Subject: Re: snap-2004-11-03 breakage References: <0b0b01c4c1a7$8a2fe3b0$0600000a@broadpark.no> In-Reply-To: <0b0b01c4c1a7$8a2fe3b0$0600000a@broadpark.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00129.txt.bz2 Hi, I definitely don't want to break applications unnecessarily and particularly applications that have been ported to several different POSIX systems, but on the other hand POSIX thread IDs are not required to be scalar. See the rationale from the definition of pthread_equal() in the Single Unix Specification version 3, which says: RATIONALE Implementations may choose to define a thread ID as a structure. This allows additional flexibility and robustness over using an *int*. For example, a thread ID could include a sequence number that allows detection of "dangling IDs" (copies of a thread ID that has been detached). Since the C language does not support comparison on structure types, the /pthread_equal/() function is provided to compare thread IDs. I don't think this is new to SUS or SUS version 3 either. Nor (given the above) does the value 0 (zero) for a thread ID have any special meaning in the standard, although it obviously does as the value returned by ec_thread_getpid() in ettercap. If you want to test if a thread exists given it's thread ID, use: if (pthread_kill(pid, 0) == 0) /* or (... != ESRCH) */ That should be portable to all POSIX implementations. I'm not dismissing your problem, but in this case I think it would be better to fix the application. Regards. Ross Gisle Vanem wrote: > snap-2004-11-03 breaks a lot of applications by the way 'pthread_t' is > defined: > > typedef struct { > void * p; /* Pointer to actual object */ > unsigned int x; /* Extra information - reuse count etc */ > } ptw32_handle_t; > > typedef ptw32_handle_t pthread_t; > > Code like (from Ettercap) > pthread_t pid = ec_thread_getpid("golem"); > if (pid != 0) > ec_thread_destroy(pid); > > no longer works; you cannot compare a struct against 0. > > I'm not sure you really meant to do that or if the typedef should be > typedef ptw32_handle_t *pthread_t; > > --gv >