This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: muto object.


On Mon, Sep 17, 2001 at 02:23:04PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf@redhat.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]