On Fri, May 20, 2016 at 8:10 PM, Ben Kelly <bke...@mozilla.com> wrote:
> On Fri, May 20, 2016 at 11:09 AM, Ben Kelly <bke...@mozilla.com> wrote: > >> On Fri, May 20, 2016 at 7:37 AM, Honza Bambas <hbam...@mozilla.com> >> wrote: >> >>> And I do! :) Actually any parent necko channel, mainly HTTP, which >>> sends data to the child process. We also have bug 1110596 which complains >>> about too much memory copying in that code. >>> Could your IPCStream be used for that? >>> >> >> Yes, I think that could work in general. >> >> I think the main issue would be compat with existing nsIStreamListeners. >> These listeners might be written such that they expect the nsIInputStream >> passed in OnDataAvailable() to return their entire length from a single >> Available() call. This will not be true for a streamed pipe. >> > > Actually, the nsIStreamListener interface explicitly requires a fixed > length nsIInputStream: > > "The onDataAvailable impl must read exactly |aCount| bytes of data before > returning." > > From: > > > https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIStreamListener.idl#18 > > I don't think we can use a pipe-oriented stream here without changing that > interface contract. > Is there a reason we can't just make necko code call OnDataAvailable() multiple times with a different slice of the giant buffer? It already has the mechanism for chunked data. It just needs to split the single buffer into multiple callouts. Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
