Re: Failing build on opensolaris

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.

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 - 14:55:01 MDT