From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11266 invoked by alias); 3 Nov 2004 16:15:53 -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 11241 invoked from network); 3 Nov 2004 16:15:50 -0000 Received: from unknown (HELO sottmailgate.ent.ad.cognos.com) (205.210.232.62) by sourceware.org with SMTP; 3 Nov 2004 16:15:50 -0000 Priority: normal Received: from sottemail1.ent.ad.cognos.com ([10.69.15.60]) by sottmailgate.ent.ad.cognos.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 11:15:49 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: snap-2004-11-03 breakage Date: Wed, 03 Nov 2004 16:15:00 -0000 Message-ID: <89B41855D8749D49850F786F27B8AB3E035796FD@sottemail1.ent.ad.cognos.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Bossom, John" To: "Ross Johnson" , "pthreads-win32" X-OriginalArrivalTime: 03 Nov 2004 16:15:49.0428 (UTC) FILETIME=[61F0F740:01C4C1C0] X-SW-Source: 2004/txt/msg00133.txt.bz2 I will awaken from my stealth lurking (Yes Ross, I'm still here!) The whole goal of the pthreads-win32 initiative is to provide an implemenation of the POSIX Threads library that is true to the standard in order to permit code portability from UNIX (& (UNIX-like i.= e linux) to Win32. Thus, any deviation from the standard will render code leveraging these features non-portable, especially if they are making any assumptions = as to the implementation of this library. There are implementations of PThreads on unix that use scalar values for ID= 's, there are also implementations that use non-scalar ids... Cheers, (and back to lurking...) John E. Bossom P.S. The original implementation of pthreads-win32 made all ID's completely= opaque pointers in order to ensure that a product that leverages the DLL doesn't have to be re= -built in order to pick up a bug fix (i.e. just drop in the fixed DLL). -----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 9:33 AM To: pthreads-win32 Subject: Re: snap-2004-11-03 breakage Hi, I definitely don't want to break applications unnecessarily and=20 particularly applications that have been ported to several different=20 POSIX systems, but on the other hand POSIX thread IDs are not required=20 to be scalar. See the rationale from the definition of pthread_equal()=20 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=20 special meaning in the standard, although it obviously does as the value=20 returned by ec_thread_getpid() in ettercap. If you want to test if a=20 thread exists given it's thread ID, use: if (pthread_kill(pid, 0) =3D=3D 0) /* or (... !=3D ESRCH) */ That should be portable to all POSIX implementations. I'm not dismissing your problem, but in this case I think it would be=20 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=20 > 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 =3D ec_thread_getpid("golem"); > if (pid !=3D 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 >=20 =20=20 This message may contain privileged and/or confidential information.= If you have received this e-mail in error or are not the intended recipie= nt, you may not use, copy, disseminate or distribute it; do not open any at= tachments, delete it immediately from your system and notify the sender pro= mptly by e-mail that you have done so. Thank you.=20 =20