[GitHub] [qpid-proton] astitcher commented on pull request #341: Change the input buffer growth logic to do something rather than nothing

[GitBox <gi...@apache.org>]

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: dev-unsubscribe@qpid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org