Boost.Threads - Open Questions from the Review

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-09-14 12:45:51

OK, I've been attempting to correct all the major concerns brought up during 
the review and I'm left with a few questions and a few things I could use 
help in resolving.

--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
>In Semaphore::up the assert:
>
>     assert(ret || GetLastError() == ERROR_TOO_MANY_POSTS);
>
>is failing for the semaphore test in thread_test.cpp, it seems as
though
>GetLastError is returning ERROR_INVALID_PARAMETER rather than
>ERROR_TOO_MANY_POSTS on my Win98 box.

I only have access to Win2K machines at this point, and I can not reproduce 
this problem nor can I see a reason for it.  I'd really appreciate it if 
anyone can explain why this is occuring.

--- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
>  - xtime.hpp uses "boost/stdint.h", which is deprecated
>and fails with como on my Linux box.  Use "boost/cstdint.hpp"
>instead (need to fix uintXX_t usage in the code as well).

I don't understand the part in parens above.  xtime.hpp uses int_fastXX_t 
types but not uintXX_t types, and I don't know of anything in the usage that 
needs fixed.

--- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
>  - Something needs to be declared "extern C", or a wrapper added:
>"once.cpp", line 45: error: argument of type "void (*)()" is
incompatible with
>           parameter of type "void (*)() C"
>         pthread_once(&flag, func);

>"thread.cpp", line 103: error: argument of type "void *(*)(void *)"
is
>           incompatible with parameter of type "void *(*)(void *) C"
>       int res = pthread_create(&m_thread, 0, &thread_proxy, &param);
>                                              ^

>"tss.cpp", line 134: error: argument of type "void (*)(void *)" is
>           incompatible with parameter of type "void (*)(void *) C"
>       int res = pthread_key_create(&m_key, cleanup);
>                                            ^

>  - If you need to add "extern C" to some function definitions, do
make
>sure to give those implementation-detail functions "static" linkage.
>An unnamed namespace won't cut it, because the namespace is not
>coded in the function name for "extern C" functions.

I need some help with all of this.

First, you can't declare the linkage as both extern "C" and static, though 
it's also true that namespaces won't help prevent conflicts for extern "C" 
functions.  So I'm not sure what to do in this case to avoid name collisions 
but use the proper language linkage specification.

Second, I'm not sure how to handle boost::call_once.  The "init routine" 
does not take any parameters in order to do the usual wrapping.  About the 
only solution I can see is to make the "init routine" be a pointer to a 
function with C linkage, but since this is a C++ API that's a little 
inconvenient.

Third, boost::thread_specific_ptr<> poses the most difficulty for me.  The 
cleanup routine must be a templated routine, which AFAICT can't be given C 
linkage.

--- In boost_at_y..., "Ed Brey" <edbrey_at_y...> wrote:
>add_thread should take an auto_ptr.  As it is, the client has to
take
>special precaution to avoid a leak when push_back fails within
>add_thread.  Also, the fact that add_thread may throw should be
>documented.

I'm not convinced that it should take an auto_ptr<> once looking at the 
code.  If you call add_thread() and the push_back() fails the thread object 
is deleted, which may prevent a leak, but it leads to other problems.  I'm 
thinking that this routine should still take a raw pointer but be documented 
that it may throw.  This way if there's a failure the calling routine can 
still access the thread through the thread object pointer in order to handle 
this error.  This may make calling add_thread() more difficult, but it 
insures that proper error handling can be done.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp