Re: Trouble compiling threads files

From: williamkempf_at_[hidden]
Date: 2001-10-10 18:20:56

--- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> 
> 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:

The good news is that most of these are already known and I'm in the 
process of addressing them.

> 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.

This code is straight from the POSIX standard and so should work.  
However, if it's a known issue on a platform I'm not adverse to 
including work arounds for that platform.  I just need more info on 
why this is occuring, what possible side effects the "fix" might 
cause to other platforms, and if we can use the Boost.Config system 
to fix only the broken platform.  If you can answer these and give me 
a patch I'll move it into the base code.
 
> 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?

I'm currently looking into this one.  I'm not sure how simple the fix 
will be so if anyone has a patch I'd be happy.  In any event this one 
will be fixed before the next release.
 
> 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.

I'm aware of this one and had thought I'd fixed most of the signed 
problems, but I'll check again.
 
> 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.

This is the one for which I started the thread about 
boost::unused_variable<>.  I will eliminate these warnings before the 
next release but I'm waiting to figure out which solution to use.

Bill Kempf