This reverts commit ed098a6dfc.
Revert "Bug 2043789: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{io,ioutils}/. r=xpcom-reviewers,emilio"
This reverts commit aa8e617fd8.
Revert "Bug 2043788: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{base,ds}/. r=xpcom-reviewers,emilio"
This reverts commit 4f52fb1147.
Before this change, the nsSegmentedBuffer would automatically dispatch
the `free` call for each individual segment to another thread, aiming to
avoid jank when freeing a large number of buffers on the main thread.
This changes that behaviour such that the responsibility to deal with
the underlying buffer is now on the caller, which has more context about
usage patterns and whether or not to batch the free calls.
Differential Revision: https://phabricator.services.mozilla.com/D235246
This is semantically similar to the existing available() method, however will
not block, and doesn't need to do the work to actually determine the number of
available bytes.
As part of this patch, I also fixed one available() implementation which was
incorrectly throwing NS_BASE_STREAM_WOULD_BLOCK.
Differential Revision: https://phabricator.services.mozilla.com/D170697
This new method can be used to check if the nsIOutputStream has been
closed without having data available to write. It should avoid blocking
to discover this information.
Differential Revision: https://phabricator.services.mozilla.com/D170696
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
This should make it slightly safer to to try to read from a
nsStorageInputStream while the stream is being concurrently written to
on another thread, though it will still not behave very well as there is
no nsIAsyncInputStream support.
Individual input streams are still non-threadsafe with this change.
Differential Revision: https://phabricator.services.mozilla.com/D142135
xpcom/io/InputStreamLengthHelper.cpp:14:22: error: unused variable 'kStreamTransportServiceCID' [-Werror,-Wunused-const-variable]
xpcom/io/SeekableStreamWrapper.cpp:422:17: error: no member named 'InputStreamHelper' in namespace 'mozilla::ipc'
xpcom/io/nsSegmentedBuffer.cpp:117:11: error: no viable conversion from '(lambda at /tmp/central/xpcom/io/nsSegmentedBuffer.cpp:117:11)' to 'void *'
xpcom/io/nsSegmentedBuffer.cpp:128:11: error: no viable conversion from '(lambda at /tmp/central/xpcom/io/nsSegmentedBuffer.cpp:128:11)' to 'void *'
xpcom/io/nsSegmentedBuffer.cpp:131:25: error: out-of-line definition of 'FreeOMT' does not match any declaration in 'nsSegmentedBuffer'
xpcom/io/nsSegmentedBuffer.cpp:143:16: error: use of function template name with no prior declaration in function call with explicit template arguments is a C++20 extension [-Werror,-Wc++20-extensions]
xpcom/io/nsSegmentedBuffer.cpp:143:16: error: use of undeclared identifier 'MakeRefPtr'; did you mean 'mozilla::MakeRefPtr'?
xpcom/io/nsSegmentedBuffer.cpp:164:35: error: implicit instantiation of undefined template 'nsTArray<std::function<void ()>>'
xpcom/io/nsSegmentedBuffer.cpp:164:44: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
xpcom/io/nsSegmentedBuffer.cpp:165:14: error: use of undeclared identifier 'mTasks'
xpcom/io/nsSegmentedBuffer.h:90:25: error: member initializer 'mTasks' does not name a non-static data member or base class
xpcom/io/nsSegmentedBuffer.h:95:25: error: no template named 'function' in namespace 'std'
xpcom/io/nsSegmentedBuffer.h:96:20: error: use of undeclared identifier 'mTasks'
xpcom/io/nsSegmentedBuffer.h:104:24: error: use of undeclared identifier 'nsTArray'
xpcom/io/nsSegmentedBuffer.h:104:38: error: no member named 'function' in namespace 'std'
xpcom/io/nsSegmentedBuffer.h:104:55: error: expected member name or ';' after declaration specifiers
xpcom/io/nsSegmentedBuffer.h:104:57: error: private field 'mTasks' is not used [-Werror,-Wunused-private-field]
xpcom/io/nsSegmentedBuffer.h:108:21: error: no template named 'function' in namespace 'std'
xpcom/io/nsStorageStream.cpp:576:3: error: no template named 'DebugOnly'
xpcom/io/nsStorageStream.cpp:576:3: error: no template named 'DebugOnly'; did you mean 'mozilla::DebugOnly'?
Differential Revision: https://phabricator.services.mozilla.com/D127040
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
Daniel Holbert