The current write path for sending data is optimized to minimize
data copies. A result of this is in SPDYStream _readData, for
fixed buffers (rather than streamed data), a non-copy NSData shard
is returned. This maps over a portion of the buffer SPDYStream owns.
Once SPDYStream goes away -- finishes writing, errors, etc -- that
buffer is no longer valid.
From _readData on, no copies are made, yet the data may get queued
for a while in SPDYSocket in the SPDYSocketWriteOp structure and its
associated queue. This could happen if other operations are queued in
front, or if the write buffer is particularly large on a particularly
slow network. Eventually we'll get to the CFWriteStreamWrite call and
tell it to consume data that may have been released.
This change maintains the "no copy" semantics but retains the original
buffer using the objc runtime. When the write completes, the original
buffer is released.
NSProgrammer
commented
9 years ago
The current write path for sending data is optimized to minimize data copies. A result of this is in SPDYStream _readData, for fixed buffers (rather than streamed data), a non-copy NSData shard is returned. This maps over a portion of the buffer SPDYStream owns. Once SPDYStream goes away -- finishes writing, errors, etc -- that buffer is no longer valid.
From _readData on, no copies are made, yet the data may get queued for a while in SPDYSocket in the SPDYSocketWriteOp structure and its associated queue. This could happen if other operations are queued in front, or if the write buffer is particularly large on a particularly slow network. Eventually we'll get to the CFWriteStreamWrite call and tell it to consume data that may have been released.
This change maintains the "no copy" semantics but retains the original buffer using the objc runtime. When the write completes, the original buffer is released.