Re: [boost] [1.47.0] Release branch now closed

Subject: Re: [boost] [1.47.0] Release branch now closed
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2011-06-17 12:36:11

On 6/17/2011 11:24 AM, Anthony Williams wrote:
> Rene Rivera<grafikrobot_at_[hidden]>  writes:
>
>> On 6/17/2011 10:36 AM, Anthony Williams wrote:
>>> Rene Rivera<grafikrobot_at_[hidden]>   writes:
>>>
>>>> On 6/17/2011 10:05 AM, Jim Bell wrote:
>>>>>
>>>>>
>>>>> On 6/17/2011 9:37 AM, Rene Rivera wrote:
>>>>>> On 6/17/2011 8:58 AM, Jim Bell wrote:
>>>>>>>
>>>>>>> On 1:59 PM, Rene Rivera wrote:
>>>>>>> The Boost.Thread patch for Mingw-64 is crucial for that important
>>>>>>> platform.<https://svn.boost.org/trac/boost/ticket/4849>
>>>>>>>
>>>>>>> It has been patched into the trunk for three months without complaint,
>>>>>>> and just needs to be shepherded to the release branch.
>>>>>>>
>>>>> I'd like a maintainer or release manager to merge the patched trunk
>>>>> files into the release branch.
>>>>>        boost/detail/interlocked.hpp
>>>>>        libs/thread/src/win32/thread.cpp
>>>>>        libs/thread/src/win32/tss_pe.cpp
>>>>>
>>>>>
>>>>> See<https://svn.boost.org/trac/boost/changeset/70383>
>>>>
>>>> Since I don't know enough to judge the code itself at this
>>>> instant.. Could others please comment on the above? Is the thread
>>>> maintainer around?
>>>
>>> The only change NOT already merged is the change to
>>> boost/detail/interlocked.hpp. I overlooked this when I merged the thread
>>> changes from trunk to release a couple of weeks ago, and I wouldn't have
>>> remembered if Jim hadn't raised the issue, since this is not one of the
>>> main thread headers.
>>>
>>> However, this is a relatively small change (some functions are no longer
>>> marked dllimport), and it only affects this one compiler, since the code
>>> expands to the same as before on other compilers.
>>
>> Could you address my other concerns I posted about?
>
> I presume you mean:
>
>> Actually, I looked at the changeset.. And I don't see how that change
>> is safe. I can see one immediate compile error/problem, 7 likely other
>> compile problems, and the high-risk of changing a header in a way that
>> impacts 3 platforms (and their related numerous compilers).
>
> I don't see the "immediate compile error/problem" or "7 likely other
> compile problems" that you see. As Jim points out, this has been on
> trunk for 3 months, without any apparent problems. If I'd remembered, I
> would have merged it when I merged the other thread changes.

I mean this compile problem:

tss_pte.cpp#14
        #if #if (defined(__MINGW32__) && !defined(_WIN64)) || defined(__MINGW64__)

I.e. the double #if.

And, at least a potential for problems depending on which CPP hits this:

extern "C"BOOST_INTERLOCKED_IMPORT long __stdcall InterlockedIncrement( 
long volatile * );

That is, the lack of space between "C" and BOOST_INTERLOCKED_IMPORT.

> I think the change is safe. As Jim points out, boost.thread will be
> unusable on mingw64 without it. If it were my choice, I'd merge it, but
> it's your call, not mine.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail