Re: omniorb log messages called from thread desctructor

On Tue, 2020-12-08 at 16:28 +0100, Michael Teske via omniORB-list
wrote:
[...]
>  In our log function  we try to get some thread-specific storage to
> identify the thread but unfortunately the _values member is already
> deleted and set to NULL in omni_thread::exit() and not in the
> destructor. Unfortunately, omni_thread::get_value does not check for
> _value but for _value_alloc, which is not reset in
> omni_thread::exit(), and thus get_value crashes.
> Is there any reason, why the _values member is not deleted in the
> omnithread destructor but in omni_thread::exit()? If 
> yes, then I think _value_alloc should be set to 0 as well.

Sorry for taking ages to reply to this!  It got lost amongst other
things.

There is a reason for deleting the thread-specific data in
omni_thread::exit if the thread is not detached. If it is not detached,
then the destructor will run in a different thread, and it is important
in some cases that per-thread data is deleted in the thread itself, not
another one.

However, it should not fail like this. I have changed it so that with a
detached thread, the per-thread data values and the array holding them
_are_ deleted in the destructor, because that happens in the thread
itself. For undetached threads, the per-thread data is still deleted in
exit(), but now it sets _value_alloc to 0 so later attempts to access
the data do not access deleted data.

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --