delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/09/17/10:57:33

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 17 Sep 2001 10:57:56 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: muto object.
Message-ID: <20010917105756.B7155@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A2C AT itdomain002 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
In-Reply-To: <EA18B9FA0FE4194AA2B4CDB91F73C0EF7A2C@itdomain002.itdomain.net.au>
User-Agent: Mutt/1.3.21i

On Mon, Sep 17, 2001 at 02:23:04PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
>> 
>> 
>> >
>> >No, you'd be ok, because thread creation and destruction is not
>> >serialised. And I don't believe it ever needs to be. You'll also note
>> >that DuplicateHandle is only called when the ownership changes. 
>> 
>> Except you don't know if a thread has been destroyed, the 
>> handle closed,
>> and then a new thread created with the same handle.  So, either you
>> don't close the handles that you created during pthread creation and
>> suffer a leak or you close them and suffer a race.
>
>Huh? MS reuse Handle ID's for threads? Ouch ouch ouch. <thinking out
>loud>Actually the problem here is that we want a handle leak, for the
>time taken to hit the muto and find the thread dead, and we don't want
>to be calling DuplicateHandle every time ownership changes. Now if we
>put the thread handle in non-TLS storage, pointed to by TLS, then the OS
>will not clean up the duplicated handle if the thread exits. So we WILL
>know that the thread hasn't been destroyed and recreated. If we
>encounter a dead thread, then by closing the handle when we recover the
>muto, we will allow the thread handle to go away, thus fixing the leak.

Assuming that we are closing the handle in the muto processing when the
muto detects that the thread has gone away, yes.  So, we have a potential
leak if the user uses mutos during the life of a thread but doesn't
use any after the thread exits.  I guess that's not a big deal.

cgf

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019