You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
No description provided.
The text was updated successfully, but these errors were encountered: