This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
This allows us to use a consistent size for the dnsFlags field.
across different files (previously some would use uint16_t and some uint32_t).
It also improves type safety - making sure we don't pass in the wrong value
to DNSFlags.
Depends on D164856
Differential Revision: https://phabricator.services.mozilla.com/D164857
This type is also used in other places to start non-initial actors, and will
allow us to attach additional state more easily without needing to thread it
through every child process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153618
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch avoids requiring the main thread to create PBackground instances by
instead using a background starter TaskQueue, and sending messages from a
PBackgroundStarter actor hosted on that thread to the target background thread
directly. On the background thread, the relevant metadata is already registered
and present in the BackgroundStarterParent actor allowing the main thread in
both processes to be bypassed completely.
Various tasks remain bound to the main thread, such as PBackground cleanup and
async steps involved in PBackground creation.
This patch also unifies the in-process and cross-process PBackground codepaths,
allowing in-process PBackground creation to bypass the main thread as well, and
removing the need for a main thread event target from
GetOrCreateForCurrentThread().
Differential Revision: https://phabricator.services.mozilla.com/D129705
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Depends on D130820
Differential Revision: https://phabricator.services.mozilla.com/D122392
