Re: Failing build on opensolaris

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)

>
> 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:08:57 MDT