Home Bug Reports

ThreadControl::ThreadControl(pthread_t)

sylvainsylvain Member Sylvain FaselOrganization: university of GenevaProject: quantum cryptographic systems ✭✭
Hi everyone at ZeroC,

this is not exactly a bug report, but I was wondering about something:

The constructor "ThreadControl(pthread_t)" is not documented (as far as I correctly read the doc) but is left public in the current distribution (I am under linux, with the latest IceE). I am wondering whether this was intentionaly done or not, and what could be the public use of this constructor.

In fact, it causes me (very little) troubles while I was implementing some threads. At some point I wanted to do the following:
"
IceUtil::ThreadControl tc(_ctrlThread->getThreadControl());
tc.join();
"
where of course _ctrlThread is of type "IceUtil::ThreadPtr".

In my first version I was distracted and I simply wrote:
"
IceUtil::ThreadControl tc(_ctrlThread);
tc.join();
"

Event of this is wrong, everything compile fine since "_ctrlThread" is converted to bool through the "operator bool() const" of Handle, and this bool value (1 in my case) is silently converted to a pthread_t.
So of course, I got segmentation fault on "tc.join()".

To conclude, I would suggest to remove "ThreadControl::ThreadControl(pthread_t)" from the public area, since it is not documented, is of no use, and could be error-prone.

I take the opportunity of this post to thank once again ZeroC for the incredible Ice system, so well designed and so useful.

Thanks in advance for your reply.

Comments

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Sylvain,

    Although this constructor is not documented, it's used internally (as you'd expect) to construct the ThreadControl from a pthread_t.

    There is really nothing "internal" about this construction, so we may as well document it. However, we should add 'explicit' to this constructor to avoid unexpected conversions.

    Thanks for reporting this issue!

    Bernard
  • sylvainsylvain Member Sylvain FaselOrganization: university of GenevaProject: quantum cryptographic systems ✭✭
    Hi Bernard,

    thanks for your reply.

    And you are right: making this constructor explicit is exactly the best idea.

    Best regards.
Sign In or Register to comment.