Proposal to change async packet processing logic #2503
Merged
+17
−15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I got recently confronted with an incompatibility between my plugin Orebufscator and RealisticSeasons. Both plugins are using async packet processing and delay the packet events (increase the processing delay). The way multiple async packet listeners are currently handled is as follows:
This means if the first listener increases the processing delay then the second listener will process the same packet in parallel. The only way listeners can acquire exclusive access to a packet is using the
processingLock
object of the packet'sAsyncMarker
. This way of handling multi-threaded access to the packet event isn't very convenient since it could lead to unnecessary locked threads (if a listener would hold the lock for the entire processing step) and potential deadlocks if multiple packets are needed to process a single packet. This is especially harmful to the performance of plugins that process the packet in their own scheduler system (Orebfuscator does that because we need to jump back and forth between processing and main thread in some instances) because this could clog up the entire scheduler (particularly if a plugin needs a long time to process a packet). Furthermore there is currently a way for badly written plugins to prematurely send a packet through multiple decreasings of the processing delay without given other listeners time to process the packet.That's why I propose the simple changes in this PR to effectively change steps 4 and 6 to also process the packet async (with processing delay reduced to zero) before calling the next listener. This way only one listener at a time can process a packet meaning the packet would always be "stable". Another way of solving this problem would be a new method for a listeners to explicitly tell ProtocolLib to only process this packet "sequentially" in that only this listener can process it and other listeners can after it's done. I would also be open for other solutions and would gladly implement them.