| components.conf |
|
473 |
| moz.build |
|
765 |
| nsIStartupCacheInfo.idl |
NOTE: this interface is completely undesigned, not stable and likely to change |
1354 |
| StartupCache.cpp |
|
31184 |
| StartupCache.h |
The StartupCache is a persistent cache of simple key-value pairs,
where the keys are null-terminated c-strings and the values are
arbitrary data, passed as a (char*, size) tuple.
Clients should use the GetSingleton() static method to access the cache. It
will be available from the end of XPCOM init (NS_InitXPCOM3 in
XPCOMInit.cpp), until XPCOM shutdown begins. The GetSingleton() method will
return null if the cache is unavailable. The cache is only provided for
libxul builds -- it will fail to link in non-libxul builds. The XPCOM
interface is provided only to allow compiled-code tests; clients should avoid
using it.
The API provided is very simple: GetBuffer() returns a buffer that was
previously stored in the cache (if any), and PutBuffer() inserts a buffer
into the cache. GetBuffer returns a new buffer, and the caller must take
ownership of it. PutBuffer will assert if the client attempts to insert a
buffer with the same name as an existing entry. The cache makes a copy of the
passed-in buffer, so client retains ownership.
InvalidateCache() may be called if a client suspects data corruption
or wishes to invalidate for any other reason. This will remove all existing
cache data. Additionally, the static method IgnoreDiskCache() can be called
if it is believed that the on-disk cache file is itself corrupt. This call
implicitly calls InvalidateCache (if the singleton has been initialized) to
ensure any data already read from disk is discarded. The cache will not load
data from the disk file until a successful write occurs.
Finally, getDebugObjectOutputStream() allows debug code to wrap an
objectstream with a debug objectstream, to check for multiply-referenced
objects. These will generally fail to deserialize correctly, unless they are
stateless singletons or the client maintains their own object data map for
deserialization.
Writes before the final-ui-startup notification are placed in an intermediate
cache in memory, then written out to disk at a later time, to get writes off
the startup path. In any case, clients should not rely on being able to
GetBuffer() data that is written to the cache, since it may not have been
written to disk or another client may have invalidated the cache. In other
words, it should be used as a cache only, and not a reliable persistent
store.
Some utility functions are provided in StartupCacheUtils. These functions
wrap the buffers into object streams, which may be useful for serializing
objects. Note the above caution about multiply-referenced objects, though --
the streams are just as 'dumb' as the underlying buffers about
multiply-referenced objects. They just provide some convenience in writing
out data.
|
11258 |
| StartupCacheInfo.cpp |
|
1493 |
| StartupCacheInfo.h |
|
692 |
| StartupCacheUtils.cpp |
At this point, if both underGre and underApp are true, it can be one
of the two following cases:
- the GRE directory points to a subdirectory of the APP directory,
meaning spec points under GRE.
- the APP directory points to a subdirectory of the GRE directory,
meaning spec points under APP.
Checking the GRE and APP path length is enough to know in which case
we are.
|
6941 |
| StartupCacheUtils.h |
|
3318 |
| test |
|
|