Type Members

1.  abstract class AbstractWorkerPool extends WorkerPool with Closeable

   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

   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.

   See also

   WorkerBlockingQueue for busy waitings example.

2.  class BusyWorkerThread extends Thread with AbstractWorker
3.  class HiredWorker extends AbstractWorker with InternalWorkerThread
4.  class SimpleClosedWorkerPool extends AbstractWorkerPool with ClosedWorkerPool
5.  class SimpleHiringWorkerPool extends AbstractWorkerPool with HiringWorkerPool
6.  class SimpleTaskController extends TaskController
7.  class WorkerBlockingQueue[A] extends BlockingQueue[A]

   This queue works like a FIFO queue, excepted that blocking operations are replaced with 'busy operations'.

   This queue works like a FIFO queue, excepted that blocking operations are replaced with 'busy operations'.

   See also

   AbstractWorkerPool for more details on the 'busy operations' (or called 'busy thread system' in the doc).

8.  class WorkerException extends AppException