This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
First, it should be called "Lookup" rather than "Get" because it returns
DataType (rather than UserDataType), but that would still be confusing,
since as opposed to other Lookup* methods, it does not return a DataType&
(and obviously, it can't). So "Extract" seems to be a better name, cf.
mozilla::Maybe::extract.
Differential Revision: https://phabricator.services.mozilla.com/D105471
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Implements the missing handle functions (OrInsertWith, OrUpdateWith), and harmonizes functions
to return a reference to the data.
Adds unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D99764
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
The existing `append` option allows to accumulate logs. The `rotate:N`
option added in Bug 1244306 allows to limit the growth of the log, but
it's both incompatible with `append` and not well suited for a single
cumulative historical log across multiple runs, since it's unclear how
to manage the current log file index across invocations. Continuously
limiting the file size for each log message is technically
challenging.
This commit pursues a much simpler approach. When `maxsize:N` is
specified with `append`, before a log file is opened, it "tails" the
file to be at most N // 2 bytes long. It tries to keep lines intact
at low runtime memory cost, but allows very long lines may be cut.
This implementation wants an atomic file rename operation, which is
supported on Win32 and POSIX OSes only at this time. On other OSes, a
compile time error will be raised.
Differential Revision: https://phabricator.services.mozilla.com/D103405
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
This is a workaround for bug 1670737 to avoid spamming a saturated
thread pool with too many events.
Also converts some unused code to a gtest.
Differential Revision: https://phabricator.services.mozilla.com/D93995
Jens Stutte
Cosmin Sabou
Simon Giesecke
Marco Castelluccio
Andreea Pavel
Mike Hommey
smolnar
Mihai Alexandru Michis
Nick Alexander
Nika Layzell
Bogdan Tara
Brindusan Cristian
Jan Varga
Andrew McCreight
Csoregi Natalia
Barret Rennie
Byron Campen [:bwc]
Valentin Gosu
Kris Maglione