[omniORB] omni_condition::~omni_condition

[Duncan Grisby]

On Saturday 20 March, glblock at rockwellcollins.com wrote:

> The poaCurrentStackInsert  creates the omni_thread_dummy by calling
> create_dummy(), at no time is a running_cond sema_ created for this object,
> but the omni_thread, or omni_thread_dummy, constructor does not initialize
> this value to NULL so it contains a random value.  When the poa calls
> realease_dummy the omni_thread_dummy's last line will 'delete dummy' this
> seems to end up in the omni_thread destructor which calls 'delete
> running_cond'.  That is where it falls apart.
> 
>  If I initialize the running_cond in the dummy constructor to NULL and put
> an if(running_cond) at the delete in the omni_thread destructor all is
> well.

This looks like a bug in the vxWorks omnithread implementation. I have
no way to test it, and I've never particularly looked at it to see if
it looks right. I don't know if initialising the running_cond to null
is right, or whether it should be initialised to a real condition
variable. Either way, if you give me a patch that works for you, I'll
integrate it.

> This may be the wrong approach but why both destructors are being called
> and other platforms dont see this I still need to understand.

It's not an issue for other platforms since running_cond is a vxWorks
specific thing.

Cheers,

Duncan.

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