Race condition in accept loop when stats are enabled

❓ I’m submitting a …

• 🐞 bug report
• 🐣 feature request
• ❓ question about the decisions made in the repository

🐞 Describe the bug. What is the current behavior?

When starting a server with monitoring enabled, there seems to be an intermittent race condition where the start time is accessed before it has been initialised, resulting in an exception.

❓ What is the motivation / use case for changing the behavior?

Fewer exceptions 😃

💡 To Reproduce

Toggle stats reporting on while a request is in progress, e.g. starting the server while an uptime monitoring query is being performed.

💡 Expected behavior

Stats are recorded.

📋 Details

Example stack trace:

[03/May/2019:14:29:50] ENGINE Bus STARTING
[03/May/2019:14:29:50] ENGINE Started monitor thread 'Autoreloader'.
[03/May/2019:14:29:50] ENGINE Serving on http://0.0.0.0:50001
[03/May/2019:14:29:50] ENGINE Bus STARTED
Exception in thread CP Server Thread-3:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/path/to/project/venv/lib/python3.7/site-packages/cheroot/workers/threadpool.py", line 121, in run
    self.work_time += time.time() - self.start_time
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'

📋 Environment

• Cheroot version: 6.5.5
• CherryPy version: 18.1.1
• Python version: 3.7.3
• OS: OS X 10.14.4
• Browser: all

📋 Additional context

I believe this is probably occurring as threadpool.py does two independent checks on self.server.stats['Enabled'] - one to initialise the start time, one to record the results. If the value of self.server.stats['Enabled'] changes while a request is in progress then we can assume there’s a chance that we’ll try the result block without the initialising the start time.

[webknjaz]

Released the patch in v6.5.7.

[jshiell]

For the record; no - and no, we don’t toggle. It just seemed to be a timing issue on startup. It looks like we fixed it by toggling thread order to give the stats reporting thread a little longer to startup.

That commit looks perfect - thanks very much @webknjaz, much obliged!