Re: Failing build on opensolaris

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.

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
>>>>
>>
Received on Tue Nov 02 2010 - 14:48:51 MDT