diff options
author | Wesley Wolfe <weswolf@aol.com> | 2012-10-07 15:08:21 -0500 |
---|---|---|
committer | Wesley Wolfe <weswolf@aol.com> | 2012-10-14 17:26:53 -0500 |
commit | 05e889f3468b07b2897d64ee1df3e26e763408b1 (patch) | |
tree | db61d53a6e329fbd5185bf2f2475fdf7aab3d5b0 /pom.xml | |
parent | 93a79cd0e646318ee23db6842cbba0acb107c389 (diff) | |
download | craftbukkit-05e889f3468b07b2897d64ee1df3e26e763408b1.tar craftbukkit-05e889f3468b07b2897d64ee1df3e26e763408b1.tar.gz craftbukkit-05e889f3468b07b2897d64ee1df3e26e763408b1.tar.lz craftbukkit-05e889f3468b07b2897d64ee1df3e26e763408b1.tar.xz craftbukkit-05e889f3468b07b2897d64ee1df3e26e763408b1.zip |
Queue tasks from secondary threads. Fixes BUKKIT-2546 and BUKKIT-2600
This change affects the old chat compatibility layer from an
implementation only standpoint. It does not queue the 'event' to fire,
but rather queues a runnable that allows the calling thread to wait for
execution to finish.
The other effect of this change is that rcon connects now have their
commands queued to be run on next server tick using the same
implementation.
The internal implementation is in org.bukkit.craftbukkit.util.Waitable.
It is very similar to a Future<T> task, but only contains minimal
implementation with object.wait() and object.notify() calls
under the hood of waitable.get() and waitable.run().
PlayerPreLoginEvent now properly implements thread-safe event execution
by queuing the events similar to chat and rcon. This is still a poor way
albeit proper way to implement thread-safety; PlayerPreLoginEvent will
stay deprecated.
Diffstat (limited to 'pom.xml')
0 files changed, 0 insertions, 0 deletions