Doug Turner wrote:
> How would this work? Well... the transport can fire a callback when a
> chunk of data could be written without blocking. This callback could be
> propogated to the caller of AsyncWrite in some fashion. The implementor
> of that callback would then supply the chunk of data.
>
>
> So suppose I am writing something using AsyncWrite. I provide you with
> a function/interface that you will call when you can and I am expected
> to give you data if I have any. Is that correct or am I missing something?
This is correct.
>
> I think that I am missing something when I look at OnDataWriteable()
> Shouldn't their be a way for me to (a) tell you when I am done writing
> and (b) tell you how much that I wrote? Or is this somehow gotten from
> the nsIOutputStream?
Since the protocol is implementing the nsIOutputStream, it
knows how much you wrote. Moreover, if you write 0 bytes
then it will know that you are finished. In other words,
just like libc read, if there are no more bytes available
then we can assume that end-of-file has been reached.
At first glance, this may seem like a synchronization headache.
Afterall, what would happen if the transport were to consume
data faster than it could be supplied? Well, the short
answer is that we have this problem with the existing
AsyncWrite interface as well. With the current interface,
the client supplies a nsIInputStream which the channel reads
from. If there are no bytes available when the channel calls
read, what should happen? The channel shouldn't busy wait and
we can't block the channel's thread, so we have to handle it
as an end-of-file.
A solution to this problem (that the client could implement)
would be to Suspend the channel if there isn't any source
data and then Resume the channel once source data becomes
available. In this way, control is left up to the client.
What do you think?
Darin
