On Wed, Feb 6, 2013 at 2:13 PM, Ken Giusti <kgiu...@redhat.com> wrote:
> Rafi, I agree with the rational behind these changes.
> > /** Return a pointer to a transport's input buffer. This pointer
> > may
> > * change when calls into the engine are made.
> I think we'll need to be a little more liberal with the lifecycle
> guarantee of these buffer pointers. Drivers based on "completion" models
> (rather than sockets) could be forced to do data copies rather than
> supplying the pointer directly to the completion mechanism.
> Could we instead guarantee that pointers (and space) returned from the
> transport remain valid until 1) the transport is released or 2) the
> "push"/"pop" call is made against the transport?
> Or perhaps a reference count-based interface would be safer? Once the
> driver determines there is capacity/pending, it "reserves" the buffer and
> is required to "push"/"pop" to release it?
I think I may have just grokked what you meant by a reference count based
interface. If you're saying that whenever the transport reports pending
output or available capacity it will preserve any exposed pointers until
after that amount of capacity/pending bytes have been pushed/popped
respectively, then I think that's a good semantic to shoot for. I wouldn't
call it ref counting as I think we could track it more simply than that.
I'd still say we should start with the more conservative semantics to get a
patch in place to fix the bug, and then narrow them to this in a subsequent