CoQ ties up a full CPU core if in the background and background music is disabled

Observed behavior:

I have the frame rate capped at 30 in the CoQ options to limit CPU usage. When CoQ is in the foreground or when background music is enabled, it does not tie up a full CPU core on my system. When CoQ is in the background and background music is off, it stops drawing anything…but now ties up a full CPU core. This consumes battery on my laptop and causes it to heat up, and even on my desktop spins up the CPU fan.

If the framerate limiter is set to “unlimited”, then a full CPU core is saturated all the time.

Expected behavior:

That CoQ not use more CPU time in the background with music-in-the-background off than it does in the foreground or in the background with music-in-the-background on.

System information:

I’m using Debian (bullseye) Linux. My assumption is that the same behavior would happen on other platforms.

Additional log data:

This shows CoQ in the background with the “play music in the background” option enabled, and the CPU core not being saturated (with futex() calls omitted to clean up the log a bit). You can see the nanosleep() calls occurring:

$ strace -e \!futex -p `pidof CoQ.x86_64` 2>&1|head -n10
strace: Process 780805 attached
read(23, 0x7fb259e60820, 768)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
read(29, 0x7fff68b2d8f0, 768)           = -1 EAGAIN (Resource temporarily unavailable)
select(9, [8], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
nanosleep({tv_sec=0, tv_nsec=28373000}, NULL) = 0
read(23, 0x7fb259e60820, 768)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)

This shows CoQ in the background with the “play music in the background” option disabled, and the CPU core being saturated; you’ll notice the lack of nanosleep() calls.

$ strace -e \!futex -p `pidof CoQ.x86_64` 2>&1|head -n10
strace: Process 780805 attached
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
read(29, 0x7fff68b2d8f0, 768)           = -1 EAGAIN (Resource temporarily unavailable)
select(9, [8], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
read(29, 0x7fff68b2d8f0, 768)           = -1 EAGAIN (Resource temporarily unavailable)
select(9, [8], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)

The nanosleep() system call is the Linux system call to sleep, and select() is usually used by “get next event” functions; thus my guess is that CoQ is probably internally explicitly calling an SDL function or Unity sleep function that is calling out to nanosleep(), and not just giving a timeout to the game framework’s main event loop when in the foreground.

‌

Comments (2)