BTW, probably the ideal approach would be to make the Mutex class itself
immune to initialization ordering problems.  That is, if you allocate a
Mutex statically, it shouldn't matter if its constructor has been run yet
when you try to lock it.  (The Mutex class in our internal codebase works
like this but is non-portable, hence the different implementation in the
open source release.)  If you want to update your patch, go ahead, otherwise
I'll take care of implementing this when it gets to the top of the queue.
 :)
On Mon, Apr 13, 2009 at 5:21 PM, Kenton Varda <ken...@google.com> wrote:

> My backlog of patches and other work is very long, unfortunately.  But I
> hope to spend some time reducing it this week, hopefully getting to this.
>
>
> On Sat, Apr 11, 2009 at 12:13 PM, Wink Saville <w...@google.com> wrote:
>
>> Has anyone been able to look at this, do I need to make some
>> changes or do anything else?
>>
>>
>>
>> On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda <ken...@google.com> wrote:
>>
>>> Although I see the decsriptor.cc part isn't meant to be submitted...
>>>
>>>
>>> On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda <ken...@google.com> wrote:
>>>
>>>> You can use "svn diff" to produce a single patch file that contains both
>>>> parts of this change.
>>>>
>>>>
>>>> On Tue, Apr 7, 2009 at 10:01 PM, Wink Saville <w...@google.com> wrote:
>>>>
>>>>> There is a bug in the initialization of the log_silencer_count_mutex_
>>>>> in common.cc.
>>>>> Currently it is initialized because it is a global object, but the
>>>>> order of initialization
>>>>> of global objects is undefined in c++ and in my environment it was not
>>>>> initialized
>>>>> when some errors were encountered as I was debugging.
>>>>>
>>>>> If descriptor.cc.patch is applied without applying common.cc.patch the
>>>>> compilation
>>>>> fails when the GOOGLE_LOG(ERROR) << "IBGF"; executes because the
>>>>> log_silencer_count_mutex_ wasn't yet initialized. It so happens that
>>>>> this actually
>>>>> fails at build time because the descriptor code is executed during
>>>>> compiliation.
>>>>>
>>>>> If you then apply common.cc.patch the compile completes successfully
>>>>> and make
>>>>> check also succeeds.
>>>>>
>>>>> The patch initializes the mutex on first use rather than at
>>>>> initialization time thus does not
>>>>> suffer the problem of the current scheme. It does make me wonder if
>>>>> there
>>>>> maybe other latent bugs in the code associated with assumed
>>>>> initialization order.
>>>>>
>>>>> Please review this patch and if additional changes are desired I'll be
>>>>> glad
>>>>> to work through any changes.
>>>>>
>>>>> -- Wink
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> >>
>>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to