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
Subject: Re: muto object.
From: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
To: cygwin-developers AT cygwin DOT com
In-Reply-To: <20010917105756.B7155@redhat.com>
References: 
	<EA18B9FA0FE4194AA2B4CDB91F73C0EF7A2C AT itdomain002 DOT itdomain DOT net DOT au> 
	<20010917105756 DOT B7155 AT redhat DOT com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13 (Preview Release)
Date: 18 Sep 2001 01:36:21 +1000
Message-Id: <1000740985.1649.1.camel@lifelesswks>
Mime-Version: 1.0
X-OriginalArrivalTime: 17 Sep 2001 15:22:53.0713 (UTC) FILETIME=[9EE91010:01C13F8C]

n Tue, 2001-09-18 at 00:57, Christopher Faylor wrote:
> On Mon, Sep 17, 2001 at 02:23:04PM +1000, Robert Collins wrote:

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

Right, and that potential 'leak' is also predicated on the user not
destroying the muto. I'll work up a patch to reflect these alterations
sometime soon. Then 95' here we come.

Rob