287750 - provide methods to test if streams are buffered

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Darin Fisher]

provide methods to test if streams are buffered

i.e., test if readSegments (or writeSegments) can be called.

Comment 1

[Darin Fisher]

Attachment: v1 patch

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 178634 [details] [diff] [review]
v1 patch

interesting...

nsStreamUtils.h
+ The test for this is to
+ * simply call readSegments, without actually consuming any data from the
+ * stream, to verify that it functions.

should this be documented? For example, might a future version of
nsIInputStream offer a function for direct testing of buffereredness, which
this function might use instead?

nsStreamUtils.cpp
+static NS_METHOD
+TestInputStream(nsIInputStream *inStr,

does this need to use PR_CALLBACK? (or PR_STATIC_CALLBACK)

Comment 3

[Darin Fisher]

> nsStreamUtils.h
> + The test for this is to
> + * simply call readSegments, without actually consuming any data from the
> + * stream, to verify that it functions.
> 
> should this be documented? For example, might a future version of
> nsIInputStream offer a function for direct testing of buffereredness, which
> this function might use instead?

well... because of the interaction with non-blocking streams, i was concerned
that consumers should understand how this check is being made.  given that
nsIInputStream is frozen, and given that there are ways for extensions to inject
their own nsIInputStream implementations, I'm not sure how we'd ever be able to
expand to test for buffered'ness directly.  that said, it is probably sufficient
to simply document the potentially odd behavior for non-blocking streams.

> does this need to use PR_CALLBACK? (or PR_STATIC_CALLBACK)

no, absolutely not.  that would crash on windows.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

>I'm not sure how we'd ever be able to expand to test for buffered'ness directly.

well, we'll need nsIInputStream2 for 64-bit available(). so, we might want to
add such a function there there.

Comment 5

[Darin Fisher]

> well, we'll need nsIInputStream2 for 64-bit available(). so, we might want to
> add such a function there there.

why do you need 64-bit available?  available is meant to indicate how much data
is available to be read from the stream right now.  that can be less than the
total size of the stream.  it is a hack that we use available to get the entire
length of the stream in other contexts.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

well, ok. but we assume that in many places. consider nsIUploadChannel:
 78      * @param aContentLength
 79      *        A value of -1 indicates that the length of the stream should be
 80      *        determined by calling the stream's |available| method.
that makes no sense unless available indicates the total length of the data.
now, this is probably a bug in the interface. but it is frozen.

hm... /netwerk/protocol/file/src/nsFileChannel.cpp, line 118 --
mStream->Available((PRUint32 *) &mContentLength);
that one should probably just stat the file (nsIFile.fileSize)

I guess we can fix all the places that assume that...

Comment 7

[Darin Fisher]

> that makes no sense unless available indicates the total length of the data.
> now, this is probably a bug in the interface. but it is frozen.

right, that's a limitation of the nsIUploadChannel interface.  if someone
chooses to pass -1 for the content length, then they must know that available is
going to be okay.  it's just there for convenience.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 178634 [details] [diff] [review]
v1 patch

sr=bzbarsky

Comment 9

[Darin Fisher]

Actually, I decided to leave the comment about the implementation since I think
it's important for callers to understand the side-effects of calling this
function.  I.e., that it is really going to call ReadSegments.

Comment 10

[Darin Fisher]

fixed

i also added lines to dlldeps.cpp so that these would be exported on win32 ;-)