Hi all,
FYI, I've landed a new IPDL type in bug 1093357 called IPCStream. This is
intended to make it easier to serialize nsIInputStreams across IPC.
In short, IPCStream:
1) Supports our existing serializable nsInputStreams.
2) Also automatically handles send file descriptors using the
PFileDescriptorSet actor
3) Supports async pipe streams using a new PSendStream actor from
*child-to-parent*. I have plans to add support for parent-to-child, but I
don't have a consumer yet and we need to figure out some issues with
PBackground targeting worker threads.
Because the actors require special care there is also a new RAII type
called AutoIPCStream.
A short example of using these types:
// ipdl
protocol PMyStuff
{
parent:
async DoStuff(IPCStream aStream);
}
// in the child
void
CallDoStuff(PMyStuffChild* aActor, nsIInputStream* aStream)
{
AutoIPCstream autoStream;
autoStream.Serialize(aStream, aActor->Manager());
aActor->SendDoStuff(autoStream.TakeValue());
}
// in the parent
bool
MyStuffParent::RecvDoStuff(const IPCStream& aIPCStream)
{
nsCOMPtr<nsIInputStream> stream = DeserializeIPCStream(aIPCStream);
// do something with the stream
}
This example and more documentation can be found in the comments in
IPCStreamUtils.h:
https://dxr.mozilla.org/mozilla-central/source/ipc/glue/IPCStreamUtils.h#31
For the most part you should be able to replace ipdl like:
InputStreamParams streamParams;
FileDescriptorSet streamFds;
With:
IPCStream stream;
Note, however, some code will assume it gets a fixed length stream from IPC
because that is all we have supported in the past. You should audit the
code to make sure it supports variable length streams.
For example, necko expects to be able to call Available() on the stream in
the parent in order to set content-length. In order to support the
IPCStream pipe mechanism necko needs to implement chunked uploads or
accumulate the stream before setting the content-length.
Right now the AutoIPCStream::Serialize() method will automatically try
serialization in this order:
1) Fixed length serialization
2) Variable length serialization
We could expand the API to favor one over the other or restrict to only one
kind of serialization.
There is one consumer using IPCStream at the moment; dom/cache. Its a bit
of a complex example, though, since Cache API needs to send arrays of
streams in a single IPC call. I tried to include adequate examples in
IPCStreamUtils.h to compensate for this.
Anyway, I hope this helps people dealing with nsInputStreams and ipdl
interfaces. Please let me know if you run into any problems or have
questions.
Thanks.
Ben
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
