Brian Ryner wrote:
I'll do some profiling to make sure it's the DB initialization that's
causing the performance hit.
I guess maybe I should have mentioned that I'm currently using these
methods through the nsICryptoHash XPCOM wrapper.
I recommend that you continue to use this API.
Using this XPCOM wrapper implementation will use a special factory
constructor in PSM, that will ensure NSS get's initialized only once.
This will happen automatically the first time any PSM XPCOM
implementation is being accessed.
In a very theoretical world, one could say, some of our PSM interfaces
can do fine without the database. One could carefully build a list of
all interfaces that do not require the database. If the first action is
such an action that does not require the database, one could do the
no-db init. The full db init could be postponed until an interface is
accessed that requires the full db. At that time one could do a NSS
shutdown and re-init with full db.
But I think this will not work in practice. The process might still
contain references to interfaces, that point to NSS variables from the
previous init. And what about multiple threads? There will be a short
amount of time, between shutdown and re-init, where NSS is not usable.
How could we ensure no thread will access a PSM interface during that time?
And I figure this solution would be also a maintenance nightmare. With
each change to PSM you'd have to verify you didn't change the list of
interfaces that require the full database init.
Please let's not do that. Please accept that using NSS requires the
database init. If you conclude that in your application you are not able
to accept the one time init cost, please consider to use a different
implementation to calculate your MD5.
So we'd either need to
change that object to know that it can do a NoDB_Init if full
initialization hasn't happened yet, or I could switch over to using the
NSS functions directly.
Are there any problems with a Firefox extension
linking directly to NSS?
Yes. Your extensions will live in the same process as the rest of
Mozilla. We need to ensure the state of NSS is correct at any given
time. Please let's continue to use the existing PSM factory constructors
to do that job.
Even if we ignore that, there is the added complexity of profile
switching. SeaMonkey still offers that feature in its UI. Embeddors
might use the Gecko engine and make use of this ability and we should
maintain it. In the past we have put a lot of work into PSM, to make it
independent of other Mozilla XPCOM code, and still ensure that we are
able to shutdown and re-init NSS. Search PSM for things like
ShutdownPreventionLocker. This requires that all NSS resources are
controlled by PSM.
Kai
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
