bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thread specific storage bug?


From: Matthew Newhook
Subject: Re: thread specific storage bug?
Date: Mon, 16 Oct 2000 13:14:21 -0230

Hi,

On Mon, Oct 16, 2000 at 05:41:16PM +0200, Wolfram Gloger wrote:
> Hello,
> 
> >   At the point that __pthread_destroy_specifics runs p_terminated is 0.
> >   So what can occur is that pthread_key_delete can set free'd memory
> >   to NULL.
> 
> I can't see how you can arrange in your program that
> pthread_key_delete() is executed _after_ __pthread_destroy_specifics()
> has free'd the 1st level keys.
> 
> pthread_key_delete() is callable from thread destructor functions,
> sure, but __pthread_destroy_specifics() only frees the 1st level keys
> _after_ all destructor functions (and hence all possible
> pthread_key_delete()'s) have been called.
> 
> Can you either explain your problem in more detail or provide a short
> test case?

I'm not calling pthread_key_delete from a thread destructor function.
It's being called in main() after my threads have (mostly) gone away.  The
problem occurs when __pthread_destroy_specifics() and pthread_key_delete
runs concurrently.

I can try and duplicate this in a short example.

> Regards,
> Wolfram.

Regards, Matthew
-- 
Matthew Newhook                         E-Mail: mailto:address@hidden
Software Designer                       WWW:    http://www.ooc.com
Object Oriented Concepts, Inc.          Phone:  (709) 738-3725



reply via email to

[Prev in Thread] Current Thread [Next in Thread]