Bug: AutoDumpTime setting of 0 doesn't play well with poll()

[dreness]

Hello,

I found a bug in ShoutCast. If I should file this somewhere else, just let me know.

The documentation for the config variable AutoDumpTime includes:

"A value of zero means there is no timeout of an idle connection."

The value of AutoDumpTime is used as the timeout argument to the poll() system call when poll()ing the file descriptors associated with network connections (on Linux and macOS; perhaps elsewhere as well?). The problem is that poll() has a different special meaning for zero. The poll() man page says the following about the timeout argument:

"Specifying a negative value in timeout means an infinite time‐out. Specifying a timeout of zero causes poll() to return immediately, even if no file descriptors are ready."

When a ShoutCast service is configured with AutoDumpTime of zero, this can result in high CPU usage because we're basically just exiting and re-entering the poll()ing loop as fast as possible. I caught this in action and did some kernel tracing to come to this conclusion; you may find the details here: https://gist.github.com/dreness/aec4...2951b27d7245f3

Note that the default value for AutoDumpTime is 30 seconds, so this bug would only bite for those who configure it to zero. I think the fix is to special-case the poll()ing code to use a value of -1 for timeout if AutoDumpTime is set to zero, to align with the special case expectations of poll() with those of ShoutCast.

Thanks!
-dre