From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13531 invoked by alias); 3 Nov 2004 16:19:06 -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 13524 invoked from network); 3 Nov 2004 16:19:05 -0000 Received: from unknown (HELO ps10.kent.dot.net.au) (202.147.78.201) by sourceware.org with SMTP; 3 Nov 2004 16:19:05 -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 1CPNqx-0000G5-00 for pthreads-win32@sources.redhat.com; Thu, 04 Nov 2004 03:19:20 +1100 Message-ID: <418904F7.8070108@ise.canberra.edu.au> Date: Wed, 03 Nov 2004 16:19: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/msg00135.txt.bz2 Alexander Terekhov wrote: >>Code like (from Ettercap) >> pthread_t pid = ec_thread_getpid("golem"); >> if (pid != 0) >> ec_thread_destroy(pid); >> >> > >Code it like > > pthread_t tid; > if (ec_thread_getpid("golem",&tid) > ec_thread_destroy(tid); > > > But how does ec_thread_getpid() portably determine if the thread exists or not? >Don't rely on idiotic pthread_kill() "testing". The standard >doesn't preclude the use of pointers for thread IDs (e.g. >inside pthread_t structure). > Oops. I should have recognised that because ... >Pointers become indeterminate and >trigger undefined behavior for any nonassignment access once >the reference storage gets freed. Conforming implementations >are allowed to reclaim/free that referenced storage when >detached thread is terminated or joinable thread is terminated >and joined. Use of "retired" pthread_t values (e.g. as >pthread_kill() argument) after that moment will trigger >undefined behavior. > > > ... that's exactly why pthread_t was changed in pthreads-win32. Every function that takes a thread ID argument has the same problem as pthread_kill() if pointers are used. Ross >regards, >alexander. > > >