From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12819 invoked by alias); 3 Nov 2004 16:18:20 -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 12810 invoked from network); 3 Nov 2004 16:18:18 -0000 Received: from unknown (HELO ps10.kent.dot.net.au) (202.147.78.201) by sourceware.org with SMTP; 3 Nov 2004 16:18:18 -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 1CPNqD-0000DR-00 for pthreads-win32@sources.redhat.com; Thu, 04 Nov 2004 03:18:33 +1100 Message-ID: <418904C8.8090706@ise.canberra.edu.au> Date: Wed, 03 Nov 2004 16:18: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: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00134.txt.bz2 Robert Kindred wrote: >On the other hand, having pthread_t to be a pointer forces me to put >compiler switches in my code that runs on both Windows and QNX. I would >appreciate knowing the general direction things are taking. > > > What specifics of pthread_t are causing you to have to treat it differently on different systems? Applications shouldn't have to know how pthread_t is actually defined. Re the general direction for the library: The library has reached a point where it's stable, except for some relatively quiet issues, such as thread ID reuse, left to fix. Defining pthread_t as a pointer meant that a new thread could acquire the same ID as a recently detached or joined thread, which could be disasterous. There were no serious bug fixes to the last snapshot and no significant fundamentally new features added. The changes to mutexes in this snapshot are also helping prepare the way for [possibly] making headway on POSIX_PROCESS_SHARED mutexes, semaphores etc. This may still prove difficult, but some more definite impedements have now been removed. This is the first time in over 6 years, if I recall correctly, that the library's ABI has changed, and there are no further changes planned. Regards. Ross >Robert Kindred > >-----Original Message----- >From: pthreads-win32-owner@sources.redhat.com >[mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Gisle Vanem >Sent: Wednesday, November 03, 2004 7:18 AM >To: pthreads-win32 >Subject: snap-2004-11-03 breakage > > >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 > > > >