The Craft Scheduler still uses the primary thread for task scheduling.
This results in the main thread still having to do work as part of the
dispatching of async tasks.
If plugins make use of lots of async tasks, such as particle emitters
that want to keep the logic off the main thread, the main thread still
receives quite a bit of load from processing all of these queued tasks.
Additionally, resizing and managing the pending entries for all of
these asynchronous tasks takes up time on the main thread too.
This commit replaces the implementation of the scheduler when working
with asynchronous tasks, by forwarding calls to the new scheduler.
The Async Scheduler uses a single thread executor for "management" tasks.
The Management Thread is responsible for all adding and dispatching of
scheduled tasks.
The mainThreadHeartbeat will send a heartbeat task to the management thread
with the currentTick value, so that it can find which tasks to execute.
Scheduling of an async tasks also dispatches a management task, ensuring
that any Queue resizing operation occurs off of the main thread.
The async queue uses a complete separate PriorityQueue, ensuring that resize
operations are decoupled from the sync tasks queue.
Additionally, an optimization was made that if a plugin schedules
a single, non repeating, no delay task, that we immediately dispatch it
to the executor pool instead of scheduling it. This avoids an unnecessary
round trip through the queue, as well as will reduce the size growth of the
queue if a plugin schedules lots of asynchronous tasks.
This seems completely pointless, as packet dispatch uses .writeAndFlush.
Things seem to work fine without implicit flushing, but incase issues arise,
provide a System property to re-enable it using improved logic of doing the
flushing on the netty event loop, so it won't do the flush on the main thread.
Renable flushing by passing -Dpaper.implicit-flush=true
* THIS IS NOT A RELICENSE *
This commit adds explicit clarification as to the state of this
project's licensing as it has always been. Nothing has changed here.
It also adds a note about how specific authors have chosen to release
their work under a more permissive license. Any past contributors who
want their name added to this list should submit a pull request here.
We will not be adding anyone's names to this list ourselves.
This will force the saves to spread over multiple ticks even when many
players auto save interval is aligned, avoiding spikes on large servers.
Closes#1021
Rather than checking the platform or operating system, simply check if
the command exists. If the check fails, check if the md5 command exists.
If that fails as well, cancel the build script. Otherwise, assign the
alias as before.
This is faster if all you need is the UUID, as .getOwner() will cause
an OfflinePlayer to be loaded from disk.
This method is already implemented on the server, just needed to expose it.