POSIX key destruction (possibly a bug?)

[Joel Sherrill]

Phil Torre wrote:
> 
> The saga of porting ACE to RTEMS continues...
> 
> My current problem involves _POSIX_Keys_Run_destructors().  A thread
> has created a key, and is now exiting.  The key's value is a pointer
> to malloc'd storage, so the destructor is run and the storage is
> free'd.  We then check the value again, and since it hasn't changed
> we set are_all_null to FALSE, loop, and try to free the same block
> again.
> 
> Should this function set the_key->Values[pthread_class][pthread_index]
> to NULL after calling the destructor?  That seems like the right thing
> to me, but I'm fairly ignorant of POSIX internals and thought I'd best
> run it past the experts.  :)

POSIX is quite complicated and used to be very expensive to 
get a copy of the standard.  Now that OpenGroup is stewarding
the standard, you can search it online at:

http://www.opengroup.org/cgi-bin/dbcgix?TPL=sd_formframes&TOKEN=BWBNB&override=sd_search

This is from the pthread_key_create man page there... 

> If, after all the destructors have been called for all non- NULL values with associated destructors, there are still some non- NULL values with associated destructors,
>      the process is repeated. If, after at least PTHREAD_DESTRUCTOR_ITERATIONS iterations of destructor calls for outstanding non- NULL values, there are still
>      some non- NULL values with associated destructors, some systems that conform to the Single UNIX Specification, Version 2 stop calling destructors, while others
>      continue calling destructors until no non- NULL values with associated destructors exist, even though this might result in an infinite loop. 

So unfortunately, I think this behavior is conformant.  But I agree with
you that I don't like it.  I think the proper changes would be to change
both RTEMS and your application as follows:

  + _POSIX_Keys_Run_destructors() should honor
PTHREAD_DESTRUCTOR_ITERATIONS
    instead of going into an infinite loop.
  + If your destructor function frees the memory, it should set the key 
    for that thread to NULL.

WOW!! I continue to be amazed at how complex POSIX can be.


> --
> 
> =====================================================================
> Phil Torre                               phone: 425-820-6363 x234
> Design Engineer                          email: ptorre at zetron.com
> Switching Systems Group                    fax: 425-820-7031
> Zetron, Inc.                               web: http://www.zetron.com
> 
> 

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985