[omniORB] omni_thread::init_t::~init_t will leak when FreeLibrary is called from a different thread as LoadLibrary

[Duncan Grisby]

On Wednesday 4 June, Martin Trappel wrote:

> When loading the omnithread33_...dll dynamically with the Win32
> function LoadLibrary() and later releasing it with FreeLibrary()
> ... when the two calls are done from different threads the dtor
> omni_thread::init_t::~init_t(void) can't do proper cleanup because
> ThreadLocalStorage is used to store the pointers for the omni_thread
> object. [see omnithread/nt.cc(455)]
> 
> What is actually the point of the
> [omnithread.h(648)] static omni_thread::init_t omni_thread_init;
> object? Why does it use TLS to remember some thread object?

The per-thread state is used to implement omni_thread::self(). All
threads created by omnithread have the TLS set appropriately, but it is
also important that the main thread has a valid return from self(). The
expectation is that the omnithread library is imported by the
application's main thread, so the init_t object is used to set the
necessary TLS for the main thread.

That is, as you see, somewhat incompatible with dynamically loading the
omnithread library from one thread and unloading it from another. I'd
welcome a patch that implements a scheme to resolve that situation, but
I'm not certain it's possible.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --