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
