astitcher commented on pull request #341:
URL: https://github.com/apache/qpid-proton/pull/341#issuecomment-969589808
Hmm, I think this may actually be the wrong approach. This bug was caused
when we moved to the proactor and connection_driver (ok - so quite a long time
ago now!) in the proactor code (epoll implementation) we have these lines
(epoll.c:1201):
```
pn_rwbytes_t rbuf = pn_connection_driver_read_buffer(&pc->driver);
if (rbuf.size > 0 && !pc->read_blocked) {
ssize_t n = read(pc->psocket.epoll_io.fd, rbuf.start, rbuf.size);
if (n > 0) {
pn_connection_driver_read_done(&pc->driver, n);
...
}
...
}
```
`pn_connection_driver_read_buffer()` calls `pn_transport_capacity()` to get
the the transport buffer so that we can find the space to read into. however at
this point we don't know how many bytes we can read so there is no way to try
to resize the buffer. `pn_connection_driver_read_done()` calls
`pn_transport_process()` to actually do the protocol processing. it looks to me
that the resizing that this change does will effectively try to make sure that
the input buffer is sized big enough for 2 of whatever buffer was just read. So
the speed up seems to come from making the buffer bigger so that fewer reads
can happen.
I wonder if we should just make the buffer resizing logic much more
explicitly in the proactor layer (or perhaps in the connection_driver layer).
This might make it a bit easier to understand the buffering strategy and to
perhaps alter it in the future,
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
