-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping packets issue with acquiring before push #9
Comments
This is a real bug. I have tried to give a fix in #8 |
Going through the implementation it's rather a consequence of the shared packetpool than a bug. Because at once a resource can only connect to one PacketToFill object, but if our PacketToFill objects haven't been pushed yet, and the channel runs out of free packets, then for the next Acquire it will return back with a null package. So for now, when we use Acquire we should always check that the returned PacketToFill object is empty or not. |
Yes, your are right. However, we should not close this issue until we also put this expected behavior into the documentation on branch docs. |
@BenBlaise You can add the missing documentation (on Channel) to docs branch after you could merge the new master into that branch. |
@BenBlaise I have merged current master into docs. I also put the missing doc lines into the docs. (And I mistakenly put the added extra docs into the merge, but no problem.) So the docs branch is either ready to merge or ready to be continued. |
Dropping packets automatically behaves unexpected when the available Packets are Acquired already, but haven't been Pushed yet.
For details check: #8 test/PolledChannelTest.cpp file PolledChannelDropPacketBeforePushTest test case.
Reason:
The freepackets is already empty, however, because the pushing of the packets haven't happened yet, the queuedpackets is also empty, so the Release method will return back with a nullptr when it tries to drop and free packet.
The text was updated successfully, but these errors were encountered: