Oh, I missed the ref counted part. D'oh! Sorry. Avi
On Mon, Sep 22, 2008 at 2:21 PM, Adam Barth <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
