From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20644 invoked by alias); 3 Nov 2004 16:32: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 20634 invoked from network); 3 Nov 2004 16:32:27 -0000 Received: from unknown (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org with SMTP; 3 Nov 2004 16:32:27 -0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA3GWQxX229824 for ; Wed, 3 Nov 2004 16:32:26 GMT Received: from d12ml062.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA3GWP1U048994 for ; Wed, 3 Nov 2004 17:32:26 +0100 In-Reply-To: <418904F7.8070108@ise.canberra.edu.au> MIME-Version: 1.0 Sensitivity: To: Ross Johnson Cc: pthreads-win32 Subject: Re: snap-2004-11-03 breakage Message-ID: From: Alexander Terekhov Date: Wed, 03 Nov 2004 16:32:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2004/txt/msg00137.txt.bz2 > But how does ec_thread_getpid() portably determine if the thread > exists or not? Define "exists" first. If you mean "tryjoin", see illustration. > Every function that takes a thread ID argument has the same problem > as pthread_kill() if pointers are used. Yes, but it's an application bug. regards, alexander. Sent by: pthreads-win32-owner@sources.redhat.com To: pthreads-win32 cc: Subject: Re: snap-2004-11-03 breakage 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. > > >