Closed
Bug 1442678
Opened 8 years ago
Closed 7 years ago
Consider adding the ability for IPDLParamTraits::Write to non-fatally error
Categories
(Core :: IPC, enhancement)
Core
IPC
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: nika, Unassigned)
Details
With the new features added in bug 1440511 it should be possible to make more types capable of being serialized easily over IPC. Unfortunately, some of these types can fail to be serialized. For example, the RefPtr<BlobImpl> type may fail to serialize in various situations where the blob is no longer available to be serialized and sent.
It would be unreasonable in many situations for this failure to cause an abort with MOZ_CRASH or similar, but it's very un-ergonomic to have to separately serialize the object and produce a parallel data structure which can be sent over IPC.
A way to fix this without changing most impls would be to make the IPDLParamTraits::Write method optionally non-fatally fallible, perhaps returning nsresult or a similar type. ParamTraits impls would not be affected. The IPDL layer could then handle propagating the errors etc, and we'd be able to send maybe-serializable types over IPC.
This would be a pretty big change, though, and may have a negative impact on IPC codegen, so I'm not sure if it's worth doing.
| Reporter | ||
Comment 1•8 years ago
|
||
I'd really appreciate your opinions on this :-)
Flags: needinfo?(nfroyd)
Flags: needinfo?(amarchesini)
Comment 2•8 years ago
|
||
(In reply to Nika Layzell [:mystor] from comment #0)
> It would be unreasonable in many situations for this failure to cause an
> abort with MOZ_CRASH or similar, but it's very un-ergonomic to have to
> separately serialize the object and produce a parallel data structure which
> can be sent over IPC.
I sympathize with this sentiment, but I don't know that the number of things that are maybe-serializable is large enough to warrant a change like this. (My sense is that the number of such types is very small, but then I'm not hip-deep in this stuff every day...) IPDLParamTraits already differs along one axis (knowing the actor), and introducing a second axis of difference doesn't feel like it's going in the right direction.
Flags: needinfo?(nfroyd)
| Reporter | ||
Comment 3•8 years ago
|
||
Makes sense. I took the approach with RefPtr<BlobImpl> of sending nullptr if the serialization failed, which I think is reasonable. Both ends can handle it, and if they need to perform custom error handling on the sending side, they can still use the old serializer system.
Updated•7 years ago
|
Flags: needinfo?(amarchesini)
| Reporter | ||
Comment 4•7 years ago
|
||
Not sure if this is necessarily useful or a good idea, so just marking as WONTFIX for now until I find a more compelling use case.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•