1603941 - Use a single channel for each tree of replaying processes

Status: RESOLVED DUPLICATE of bug 1606447

(Core Graveyard :: Web Replay, enhancement)

Description

[Brian Hackett [Laid off!]]

After bug 1597149, when a replaying process forks the middleman has to establish a separate communication channel with the forked process. This works fine locally but doesn't seem like a good plan as we move further along with cloud integration --- there could be hundreds of forked processes which a middleman might need to communicate with, and establishing separate channels requires lots of system resources in the middleman, which will be slow to perform, tricky to clean up properly, and might bump into OS limits on the number of file descriptors the middleman process can open at once.

It would be better for the middleman if it only had one communication channel with each replaying process it directly spawns, either locally or remotely in the cloud. That channel will be used to communicate that replaying process and all other replaying processes which it has transitively forked. Those root replaying processes will have some extra complexity as they need to act like a multiplexer/demultiplexer in dispatching messages between the middleman and forked processes, but this fits in well with other needs for mutable state that must be shared between the forked processes, like the recording contents.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: Bug 1603941 - Use a single channel for each tree of replaying processes, r=jlast.