From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19785 invoked by alias); 4 Nov 2004 18:06:19 -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 19768 invoked from network); 4 Nov 2004 18:06:16 -0000 Received: from unknown (HELO viruswall.ccf.swri.edu) (129.162.252.34) by sourceware.org with SMTP; 4 Nov 2004 18:06:16 -0000 Received: from RKINDREDXP (localhost [127.0.0.1]) by viruswall.ccf.swri.edu (8.12.10/8.12.6) with SMTP id iA4I69wI027323; Thu, 4 Nov 2004 12:06:10 -0600 (CST) Reply-To: From: "Robert Kindred" To: "Ross Johnson" , "pthreads-win32" Subject: RE: snap-2004-11-03 breakage Date: Thu, 04 Nov 2004 18:06:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-reply-to: <418904C8.8090706@ise.canberra.edu.au> X-SW-Source: 2004/txt/msg00138.txt.bz2 > -----Original Message----- > From: pthreads-win32-owner@sources.redhat.com > [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Ross > Johnson > Sent: Wednesday, November 03, 2004 10:18 AM > To: pthreads-win32 > Subject: Re: snap-2004-11-03 breakage > > > 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. Let me take a quick look at my code... Oops, I typed too soon. I am not actually switching on a pthread_t. I am switching code on a pthread_mutex_t. I must create and initialize these differently on the two platforms. Perhaps there is a portable way that I don't know about? > > 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 > > > > > > > > > >