Being a non-blocking queue it will allow the caller to continue submitting tasks up to the limit of the memory. When using WorkerPool if there is a chance of submitting more tasks that can be safely stored in memory, then there should be some means (outside of workerpool) to stop submitting tasks before this limit.
A modified WorkerPool could be given a limit to the number of queued tasks it will enqueue and then handle additional submissions by blocking or by discarding tasks. The reason that WorkerPool does not handle this is that these functionalities can be added by the caller, and how they are handled are likely application-specific.
In the case of the blocking queue, the application can determine when it is in a low-resource condition and then stop submitting new tasks while the condition persists. Or, if limiting the queued tasks, can stop submitting more until the number of incomplete tasks decreases.
In the case of discarding, what to discard is going to be up to the application (oldest, random, lowest priority, etc.) The task function itself, or a task function wrapper, would check the discard condition and exit immediately if it is discarded, possibly sending a notification that it was discarded.
Prince-Hervoet
commented
1 year ago
Being a non-blocking queue it will allow the caller to continue submitting tasks up to the limit of the memory. When using WorkerPool if there is a chance of submitting more tasks that can be safely stored in memory, then there should be some means (outside of workerpool) to stop submitting tasks before this limit.
A modified WorkerPool could be given a limit to the number of queued tasks it will enqueue and then handle additional submissions by blocking or by discarding tasks. The reason that WorkerPool does not handle this is that these functionalities can be added by the caller, and how they are handled are likely application-specific.
In the case of the blocking queue, the application can determine when it is in a low-resource condition and then stop submitting new tasks while the condition persists. Or, if limiting the queued tasks, can stop submitting more until the number of incomplete tasks decreases.
In the case of discarding, what to discard is going to be up to the application (oldest, random, lowest priority, etc.) The task function itself, or a task function wrapper, would check the discard condition and exit immediately if it is discarded, possibly sending a notification that it was discarded.