Re: Failing build on opensolaris

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.

I am suggesting to leave it as is ....

>
> HTH,
>
> 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
>>>>>
>>>
>
>

-- 
Tsantilas Christos
Network and Systems Engineer
email:christos_at_chtsanti.net
   web:http://www.chtsanti.net
Phone:+30 6977678842