[omniORB] copy constructor of omni_mutex, omni_condition doc inconsistency

[Grohmann, Axel]

Hello developers,

recently I was running into problems because I was copy-constructing an object
containing an omni_mutex. This lead to the copy constructor of omni_mutex being
called. It seems to me that this copy constructor is not implemented but is
automatically generated by the C++ compiler. This lead to strange program behaviour
(maybe underlying pointers are simply copied,....).

I am not sure what semantics a copy constructor of a mutex could have. If there is
a sensible one (e.g. constructing a new mutex with the same state(locked/unlocked)
) that is implemented, then I would like to have it documented. Otherwise I would
suggest that the copy constructor is declared private but not implemented, which
would have lead to a compile-time error in my case (copy-constructing an object
containg mutexes). This would have forced me to write a copy constructor for my
object taking care of contained omni_mutexes.

By the way, there seems to be an inconsistency between the omnithread documentation
and the code in that the doc says that an unsuccessful call to
omni_condition::timed_wait(...) would return EAGAIN. It now returns 0 instead.

However, apart from these minor issues I really like using omniORB. It also seems
to me that the previously raised question about commercial support for omniORB is a
very good idea to promote this excellent work.

Cheers,
Axel Grohmann


Department of Knowledge Engineering and Numerics
Institute of Nuclear Energy and Energy Systems
University of Stuttgart
Pfaffenwaldring 31
70550 Stuttgart
Germany
Phone: ..49 711 685-2130
Fax: ..49 711 685-2010