LaKraven
commented
9 years ago Notes to Self:
- When DECREASING the size of the Thread Pool, have the least-populated Thread(s) (however many need to be dropped in order to attain the specified pool size) redistribute their queued Events amongst the remaining Threads and terminate themselves once done.
- Default the size of a Thread Pool to match the number of CPU cores available on the system unless an explicit size is specified for the constructor.
- When an Event is dispatched to the Pool (either Directly or through the standard Queue/Stack dispatch methods of TLKEvent), determine the best possible Thread in the pool to pass it over to. This could mean allowing the implementing developer to define a "Threshold" after which that Thread is put into "only if I'm the best of the bunch" mode so-as to reduce dispatch overhead. Generally speaking, and for the sake of initial implementation, the best Thread to pass the Event along to should be considered the Thread with the least Events waiting in its Queue + Stack. (More complex deterministic methods can be implemented later!)
- Caveat to the above: if there are vacant Threads, the Event should be passed to them REGARDLESS of any Threshold specification.
Basically you inherit from "TLKEventThreadPooled" to define one or more operations to be performed when that Thread is provided with a TLKEvent descendant for which it has registered a Listener, just as you do currently with TLKEventThread.
However, you don't create an instance of a "TLKEventThreadPooled" descendant directly, but instead through a "TLKEventThreadPool".
"TLKEventThreadPool" manages multiple instances of its associated "TLKEventThreadPooled" Type, and balances the workload (in the form of Events) between them.
Think of this like an Event-Driven alternative to classic "Worker Threads", but using the same Persistence model as the rest of the Event Engine (which reduces operational overhead)