Closed Bug 1494469 Opened Last year Closed 5 months ago
_MESSAGE _SIZE is not the maximum IPC message size
47 bytes, text/x-phabricator-request
|Details | Review|
The actual maximum size for an IPC message, after serialization and headers and so on, is IPC::Channel::kMaximumMessageSize — which, at the time of this writing, is 256 MiB. There is also an IPC::MAX_MESSAGE_SIZE, which is 64 KiB, or 1/4096 of the actual maxmimum message size. The history of this error seems to start with me, while doing the e10s for nsWebBrowserPersist (bug 1101100), picking 64KiB as an arbitrary block size for streaming the serialized document over IPC. My comment, “Limit the size of an individual IPC message”, was apparently misinterpreted — I don't think it occurred to me that someone would see it and read it that way — and bug 1106321 promoted that misunderstanding to a definition in ipc/glue. It would be nice if that could be fixed, especially because this may be causing unnecessary failures in Windows printing. The general idea behind the 64k was that small messages mean more per-message overhead, but large messages are potentially bad for latency of other messages on the same channel (e.g., for WebBrowserPersist, that's the entire PContent tree). However, I don't think we have any data to suggest a recommended message size.  https://searchfox.org/mozilla-central/rev/ce57be88b8aa2ad03ace1b9684cd6c361be5109f/ipc/chromium/src/chrome/common/ipc_channel.h#53  https://searchfox.org/mozilla-central/rev/ce57be88b8aa2ad03ace1b9684cd6c361be5109f/ipc/glue/IPCMessageUtils.h#111
We should add a comment to https://searchfox.org/mozilla-central/rev/ce57be88b8aa2ad03ace1b9684cd6c361be5109f/ipc/glue/IPCMessageUtils.h#111
Priority: -- → P3
(In reply to Jim Mathies [:jimm] from comment #1) > We should add a comment to > > https://searchfox.org/mozilla-central/rev/ce57be88b8aa2ad03ace1b9684cd6c361be5109f/ipc/glue/IPCMessageUtils.h#111 What we should do, I think, is delete that definition entirely; instead, nsWebBrowserPersist can get its old constant back, with a better comment this time, and the Windows printing thing can use something like (IPC::Channel::kMaximumMessageSize / 2). If we really want to set out a globally recommended size for sending data chunks over IPC, there should be some actual data to justify it.
Attachment #9053738 - Attachment description: Bug 1494469 - Removed duplicate IPC::MAX_MESSAGE_SIZE constant → Bug 1494469 - Removed duplicate IPC::MAX_MESSAGE_SIZE constant r=jld
Flags: needinfo?(hijitsuhisa) → needinfo?(jld)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e25e95c59e6b Removed duplicate IPC::MAX_MESSAGE_SIZE constant r=jld
You need to log in before you can comment on or make changes to this bug.