Attention is currently required from: laforge, pespin.
5 comments:
Commit Message:
Patch Set #3, Line 17: This change ensures that newly received data is appended to the existing
First you say we don't want to reuse the pending buffer, but here you say "This change ensures that […]
Maybe I should state that I don't want to reuse the pending buffer for the read operation. Instead I copy from the buffer that was used for the read operation to the pending buffer.
File src/core/osmo_io.c:
Patch Set #3, Line 177: /*! convenience wrapper to call msgb_alloc with parameters from osmo_io_fd (with extra size) */
"with extra size" here doesn't apply anymore?
Done
Patch Set #3, Line 178: struct msgb *iofd_msgb_alloc2(struct osmo_io_fd *iofd, size_t size)
This is probably breaking the promise that msgb passed to the app are at least of a certain size con […]
In case the pending buffer is used, the size may be larger, but never smaller. I don't see any problem with that. It happens when reading/receiing. The application should only care about the length of data in the buffer not the size.
Patch Set #3, Line 335: * If the pending message is not large enough, create a larger message. */
I may be wrong, but I'd expect user to configure iofd with a max_size big enough to allow whatever s […]
Imagine the pending buffer is almost full. Now we read extra data that is larger than the remaining space of the pending buffer. In order to merge them, a larger buffer is needed.
Patch Set #3, Line 344: memcpy(msgb_put(iofd->pending, msgb_length(msg)), msgb_data(msg), msgb_length(msg));
Can we avoid 2 memcpys (here and above) in the specific code path?
How? The fist memcopy is used, if the pending buffer must be enlarged. The second memcopy will append the newly received data to the pending buffer.
To view, visit change 40584. To unsubscribe, or for help writing mail filters, visit settings.