This class handles a FixedThreadPool from Java executors, excepted that the used threads can be busy about executing other tasks contained in the pool instead of stupidly waiting in an object monitor

Problem

Let's say that we have a pool of 3 threads that handle deserialization and packet injections.
(see fr.linkit.api.gnom.packet.traffic.PacketInjectable for further details about injection) Then suddenly, for a reason that can often appear, every threads of the pool are waiting to receipt another packet.
The waited packet will effectively be downloaded by the PacketReaderThread, but it could not be deserialized and injected because all the thread are currently waiting for an injection.
This way, a kind of deadlock will occur because each threads are waiting for their packet to be injected, and there is no free thread in the pool that would process the packet injection

Pseudo code :

Here is an illustration of a normal execution.
Where the first thread is waiting for a packet to be received, and where a second thread is injecting the packet in the channel.

<u>Thread 1 : waiting for a packet to be received

val channel = connection.getInjectable(x, ChannelScope.y, SyncPacketChannel)
val nextPacket = channel.nextPacket()
println("A new packet has been received !")
// Process nextPacket....

<u>Thread 2 : injecting the next packet that concerns the channel, handled by the thread 1.</u>

val injectable = //Retrieves the needed injectable, stored with 'x' identifier
val packetInjection = //Get the concerned injection object
injectable.injectPacket(packetInjection) //The injection will notify the first thread.
//println("Another packet injection has been performed !")

Solution

In a normal execution, where a second thread is free to notify the first thread, the two prints would be done successfully

Therefore, if the second thread were not able to handle the injection, because it would be busy to execute another task submitted to the thread pool, the first thread could not be notified, and will wait until a thread is free to process the injection.
But we have to rely on the fact that the first thread is doing noting.
But, are we saying that we have a thread that is stupidly waiting for a packet to be provided, and will do absolutely nothing until he does not received its wants, where he can take the time he is sleeping for executing other tasks in the pool ? and thus consequently injecting his own packet to unlock itself ? What a lazy thread !

The Busy thread system will save this lost time in order to fluidify task execution, and make one thread able to handle multiple tasks even if a task needs to wait a Linkit resource.