Repository navigation
Async message processing. #91
Description
There are some instances where the AsyncPlayerChatEvent isn't actually async which means all the message processing is done on the main thread. I believe this happens when the player's message is sent using the spigot api but possible in other instances as well. We need to detect those instances and execute the code on another thread.
Activity
Jaimss commentedon Jul 21, 2022
All you should need to do is check
Event#isAsynchronous(). No special detection or anything should be necessaryI can PR this if you want
BlitzOffline commentedon Jul 21, 2022
Yes, that's true, but there's a pr that changes some stuff (the one that cancels AsyncChatEvent when ChatChatEvent is cancelled) so idk. I really can't be bothered to think rn. If you think you can make it work with that PR, then sure.
Jaimss commentedon Jul 22, 2022
So I've done some work on this and as far as I can tell it's not going to be possible to make it work the way it needs to.
If
AsyncPlayerChatEventis fired async, everything works fine.If
AsyncPlayerChatEventis fired sync, there are some issues. You can't perform async computations or processing and then use those results to update the event. So#setMessage(),#setFormat(),#setCancelled(), etc. don't work. The way things are set up currently, those things depend on processing, which should be done asynchronously, but you can't update them with that async value unless you block the main thread and wait for the async processing to complete, which defeats the purpose.I believe the only way to ensure that the processing is always completed async is to cancel the
AsyncPlayerChatEvententirely and handle the console format, sending the message, etc. entirely on your own, although I may be overlooking a simple solution lol.I believe
AsyncPlayerChatEventonly gets called synchronously when a plugin usesPlayer#chat(), so it isn't something that will happen very often.BlitzOffline commentedon Jul 22, 2022
We can't cancel the APCEvent. That's because plugins like DiscordSRV, listen to that event with the MONITOR priority. I knew this will be an issue that's why I didn't take on this task yet. Also the addition of bungee support will require us to completely redo the MessageProcessor class since right now it is a mess.
Btw we only take the result from the process method which tells us if the event should continue running or if it should be cancelled.