Re: Failing build on opensolaris

On 11/03/2010 09:08 AM, Tsantilas Christos wrote:
> On 11/03/2010 04:54 PM, Alex Rousskov wrote:
>> On 11/03/2010 02:49 AM, Christos Tsantilas wrote:
>>> On 11/02/2010 04:48 PM, Alex Rousskov wrote:
>>>> On 11/02/2010 05:34 AM, Tsantilas Christos wrote:
>>>>> On 11/02/2010 12:42 PM, Amos Jeffries wrote:
>>>>>> On 02/11/10 23:27, Tsantilas Christos wrote:
>>>>>>> Hi all,
>>>>>>> This problem caused by my last commit. If I am not wrong should
>>>>>>> fixed
>>>>>>> now by Amos r11000 commit.
>>>>>>> I lost the related "Build failed" message and this discussion (I
>>>>>>> lost a
>>>>>>> lot of thinks :-( )
>>>>>>>
>>>>>>
>>>>>> r11000 uses a temporary pointer. Just a workaround, not a proper fix.
>>>>
>>>>> It is not so bad. But I am not sure if it passes Henrik requirements
>>>>> about the use of cbdataReference/cbdataReferenceDone
>>>>>
>>>>> Is the CbcPointers a good choise?
>>>>>
>>>>>> Alexs' suggested fix of using the CbPointer type properly for that
>>>>>> variable is better if anyone has the time to do it.
>>>>>
>>>>> With a first look it is very easy to use CbcPointers. Give me some
>>>>> time,
>>>>> I will make a simple patch.
>>>>
>>>> Before you consider using CbcPointer, consider removing the offending
>>>> cbdataReference() call instead. If my quick check is correct, the call
>>>> is not needed at all. If you remove the call, you need to remove
>>>> cbdataReferenceDone() in clientdbFreeItem() as well, of course; simply
>>>> deleting the queue there should be sufficient.
>>>
>>> We can not remove the cbdataReference/cbdataReferenceDone because the
>>> ClientInfo::quotaQueue passed as argument to commHandleWriteHelper
>>> function which executed as event.
>>
>> Events call cbdataReference/cbdataReferenceDone on their own, right? We
>> do not need to double that effort as far as I can see.
>
> Yes events uses the cbdataReference/cbdataReferenceDone but if we do not
> lock cbdata before pass to an event the cbdata will be deleted after the
> event done (when the cbdataReferenceDone called)

I do not think it will be deleted if it is still valid (i.e., if the
owner still points to it):

> if (c->valid || c->locks)
> return;

Alex.

>>>>>>> On 10/29/2010 12:28 PM, Henrik Nordström wrote:
>>>>>>>> tor 2010-10-28 klockan 22:26 +0200 skrev Kinkie:
>>>>>>>>
>>>>>>>>> Well, my aim is a very modest "let the damn thing build".
>>>>>>>>> I do not yet understand the intricacies of cbdata, and thus I am
>>>>>>>>> not
>>>>>>>>> able to understand when it is abused and when the abuse is benign.
>>>>>>>>
>>>>>>>> There is two cbdata roles
>>>>>>>>
>>>>>>>> a) Object owner, using "plain pointer" and freeing the object using
>>>>>>>> cbdataFree when done.
>>>>>>>>
>>>>>>>> b) Other code needing to to a callback to the object owner passing
>>>>>>>> the
>>>>>>>> object for owner state info. Uses cbdataReference to track the
>>>>>>>> object
>>>>>>>> and cbdataReferenceValid& cbdataReferenceDone (or usually preferred
>>>>>>>> the
>>>>>>>> combined cbdataReferenceValidDone) when making the callback.
>>>>>>>>
>>>>>>>>
>>>>>>>> Different cases of abuse:
>>>>>>>>
>>>>>>>> * use of the return value of cbdataReference as a pointer to some
>>>>>>>> specific type of object. The API intention is to consider it
>>>>>>>> anonymois
>>>>>>>> "void *" where the actual data type is only known by the object
>>>>>>>> owner.
>>>>>>>>
>>>>>>>> * use of cbdataReference as a refcount substitute. (we did not have
>>>>>>>> refcount when cbdata was added)
>>>>>>>>
>>>>>>>> * no clear separation between "owner" and "other code needing to
>>>>>>>> do a
>>>>>>>> callback".
>>>>>>>>
>>>>>>>> * Direct uses of cbdataInternal* calls.
>>>>>>>>
>>>>>>>> * use of cbdata as a simple way to set up pooled allocation even
>>>>>>>> when
>>>>>>>> the object is never intended to be used in callbacks.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Keep in mind that a lot of cbdata-using code violates these very
>>>>>>>>>> good rules,
>>>>>>>>
>>>>>>>> I would not say "a lot". There is some abuses, but most of the code
>>>>>>>> uses
>>>>>>>> it right, at least last time I audited cbdata usage.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Henrik
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
Received on Wed Nov 03 2010 - 15:41:05 MDT