From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pthreads-win32-return-876-listarch-pthreads-win32=sources.redhat.com@sources.redhat.com>
Received: (qmail 29492 invoked by alias); 3 Nov 2004 15:32:51 -0000
Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:pthreads-win32-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/pthreads-win32/>
List-Post: <mailto:pthreads-win32@sources.redhat.com>
List-Help: <mailto:pthreads-win32-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: pthreads-win32-owner@sources.redhat.com
Received: (qmail 29465 invoked from network); 3 Nov 2004 15:32:50 -0000
Received: from unknown (HELO mtagate2.de.ibm.com) (195.212.29.151)
  by sourceware.org with SMTP; 3 Nov 2004 15:32:50 -0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA3FWgxD206846;
	Wed, 3 Nov 2004 15:32:42 GMT
Received: from d12ml062.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA3FWfKt186508;
	Wed, 3 Nov 2004 16:32:41 +0100
In-Reply-To: <0b0b01c4c1a7$8a2fe3b0$0600000a@broadpark.no>
MIME-Version: 1.0
Sensitivity: 
To: "Gisle Vanem" <giva@bgnett.no>
Cc: "pthreads-win32" <pthreads-win32@sources.redhat.com>
Subject: Re: snap-2004-11-03 breakage
Message-ID: <OF1A7C794E.5AC63D51-ONC1256F41.00533C1C-C1256F41.00556751@de.ibm.com>
From: Alexander Terekhov <TEREKHOV@de.ibm.com>
Date: Wed, 03 Nov 2004 15:32:00 -0000
Content-Type: text/plain; charset="US-ASCII"
X-SW-Source: 2004/txt/msg00131.txt.bz2

> 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);

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). 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. 

regards,
alexander.