I don't quite understand your question. Clients of X509Certificate should be oblivious of the cache. A client obtains a pointer to a certificate via the factory method and stores the pointer in a scoped_refptr. Once the client is done with the cert, the scoped_refptr is destructed, which results in a Release call on the certificate object. If the cert's refcount goes to zero, then the cert destructs itself and removes itself from the cache.
The cache's job is to make sure we only have one instance of every unique cert at every point in time. The cache does not increase the lifetime of any of the certificates. Adam On Mon, Sep 22, 2008 at 11:13 AM, Avi Drissman <[EMAIL PROTECTED]> wrote: > I'm trying to wrap my head around a design decision in x509_certificate. > > The class provides two factory functions that keep a cache of certs. If a > cert is requested, and it's already in the cache, the cached version is > used. > > But we also provide a destructor, which removes the cert from the cache. > > So is the caller to the factory function supposed to call the destructor of > the x509_certificate pointer that it gets back from the factory, or not? If > so, then we have a ref-counting problem, where we'll die on the second > person to release a uniqued cert. If not, we just cache forever, but then > why provide a destructor? > > Avi > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
