Optionally disabling separate thread/SPSC queue

[Evador]

The use case is the following:
I have different applications all using quill for logging. Some of them are latency sensitive and others aren't. In the latter case there could be many processes of the same application running on a single server (e.g. 50 copies of the same application run on a server with 8 cores and they share resources).

I wonder if there is any way to switch quill to the naive mode: where logging happens in the same thread or there is no spin lock in the queue? The issue is I'm facing is that the server is always 100% loaded though applications themselves are lightweight and they don't log much.

The option QUILL_IMMEDIATE_FLUSH doesn't really help here since spinning SPSC queue is still there.

[odygrd]

Currently, there is no sync logging mode implemented. Implementing this is not straightforward because everything is built to run asynchronously :(

Some Suggestions

• Pin all backend logging threads of non-critical applications to the same core (e.g., core 0)
  Optionally, it's fine to pin all backend logging threads, even for critical applications, to a single core.
  With 50 copies, you will get 50 backend logging threads. It's very inefficient having all those threads context-switching and affecting all other applications.
  BackendOptions.h: L145

• For non-latency critical applications, set the backend sleep duration to a higher value (e.g., 1 second)
  This will stop the backend thread from waking up and spinning each time. It will wake up less frequently, process all batches of logs, and then go back to sleep.
  BackendOptions.h: L49

• Optionally, for non-latency critical apps, you can set the sleep duration to a very high value and wake up the backend worker thread on demand
  Backend.h: L131

Example: Manually Waking Up the Backend Worker Thread

Here is an example where you manually wake up the backend worker thread. You could call this, for example, after logging in a non-critical application or after issuing some logs.

Example:
backend_thread_notify.cpp

Let me know if any of these suggestions were helpful!

[Evador]

Thanks for the reply! I think one of those 2 ideas should help to resolve the issue.

[Evador]

Realised that even for latency sensitive applications logging latency is not that important (only the latency of the main thread is important) so I can always use 1 second sleep duration

[odygrd]

It depends how much a latency critical app is logging, if it logs too much within 1 second the SPSC queue can become full and trigger a reallocation to grow