The queue depth limits added in #88 provide a limit to the amount of entries that can be added to a single queue at a single event, but it is not fully utilized because the limit is very high. To make this more effective, the limits should be reasonably low, but this requires the ability to yield and reschedule/resume work queues and that is not currently implemented.
That is, if pulling bundles from storage to go be sent to a CLA that has an active contact, those bundles only go into the storage output queue - They still need to be forwarded to the CLA for actual transmission, which is a separate work task. This means there either needs to be a separate thread to handle that forwarding task, or that the storage retrieval work needs to voluntarily yield to the other pending work item.
The ideal implementation may actually have both - such that it fills the output, and then yields to another thread until it has reached a half-full point, then resumes. But in a single-threaded implementation it still works, where the same worker thread can simply switch its focus to the other work task, and then switch back again at the next yield point (a form of cooperative multitasking with a single worker).
The queue depth limits added in #88 provide a limit to the amount of entries that can be added to a single queue at a single event, but it is not fully utilized because the limit is very high. To make this more effective, the limits should be reasonably low, but this requires the ability to yield and reschedule/resume work queues and that is not currently implemented.
That is, if pulling bundles from storage to go be sent to a CLA that has an active contact, those bundles only go into the storage output queue - They still need to be forwarded to the CLA for actual transmission, which is a separate work task. This means there either needs to be a separate thread to handle that forwarding task, or that the storage retrieval work needs to voluntarily yield to the other pending work item.
The ideal implementation may actually have both - such that it fills the output, and then yields to another thread until it has reached a half-full point, then resumes. But in a single-threaded implementation it still works, where the same worker thread can simply switch its focus to the other work task, and then switch back again at the next yield point (a form of cooperative multitasking with a single worker).