Trouble compiling threads files

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-10-10 15:23:38

Hi Boosters, and Boost threaders. I'm trying to make use of 
Boost.Threads in a Solaris environment, compiling with g++-2.95.2 
--pedantic. We have pthreads, but there are a few problems:

1) (Less serious) the statement 
pthread_once_t once = PTHREAD_ONCE_INIT ;

(occurs twice) triggers a warning:
/work/nova/2465/once.cpp:27: warning: aggregate has a partly bracketed 
initializer

I think this is a defect in the locally installed pthreads headers, as 
this statement is identical to one in the documentation. (I *think* g++ 
is technically correct to diagnose this -- the pthread_once_t is struct 
{ <someintegertype> __xxx[4] } on this system. Is this a difference 
between C and C++ here?). In any case, using { PTHREAD_ONCE_INIT } 
instead fixes this problem. I don't think Boost ought to do anything 
about this error, but Solaris people might be interested in it.

2) (More troublesome) in once.cpp, 
once_callback cb = reinterpret_cast<once_callback>(pthread_getspecific(k
ey));

fires an error, complaining that:

/work/nova/2465/once.cpp: In function `void {anonymous}::do_once()':
/work/nova/2465/once.cpp:41: ANSI C++ forbids casting between pointers 
to functions and objects

This is, I think, strictly correct. It is arguably a flaw in the 
standard that a pointer to an extern "C" function cannot be converted 
back and forth with a void *, since C allows that behavior, but I could 
find nothing in the standard that excepted extern "C" functions from 
the conversion rules.

I'm not sure I understand the subtleties of this code, so I was 
reluctant to simply add the proverbial extra layer of indirection. I 
think it will require dynamic allocation, which may just screw up the 
whole point (?). Comments, thoughts?

3) (Smallish issue) In timeconv.inl, I get complaints about comparing a 
signed to an unsigned, comparing the members of xtime with the 
locally-defined consts. Recognizing that a 32-bit signed int can hold 
+10^9 (nanoseconds per second), or even 2*10^9 (adding two 10^9 - 1 
nano-second numbers), I just changed the consts to be straight ints. 
Other fixes are possible, of course.

4) (Not serious at all, but would be nice to have fixed): There are 
unused-variable warnings in mutex.cpp, where state is not used in the 
three do_lock functions.

George Heintzelman