All the examples use polling model, and sleep for 1 nanosecond between polls. This will require those applications to use 100% of the CPU all the time, whether there is work for them or not.
Is QuestDB written like that? If yes, this is a great reason to avoid it.
There is an option to park threads, publisher can signal the consumer if needed.
This model is non-blocking to allow applications to have fewer thread and those threads to process more than one queue or more generally do more than one task. The rationale here is that waking threads up and parking them dramatically increases queue latency.
QuestDB is indeed using this model, but it does not have dedicated threads for each queue. Each thread is able to back-off filling up an already full queue and instead take role of consumer and drain the queue instead. Having non-blocking queues helps to promote work stealing and generally doing other tasks in the same thread.
2 comments
[ 2.2 ms ] story [ 17.2 ms ] threadIs QuestDB written like that? If yes, this is a great reason to avoid it.
This model is non-blocking to allow applications to have fewer thread and those threads to process more than one queue or more generally do more than one task. The rationale here is that waking threads up and parking them dramatically increases queue latency.
QuestDB is indeed using this model, but it does not have dedicated threads for each queue. Each thread is able to back-off filling up an already full queue and instead take role of consumer and drain the queue instead. Having non-blocking queues helps to promote work stealing and generally doing other tasks in the same thread.