Server shutdown code fails when trying to signal "user" threads
Originally reported by: **Anonymous**

---

On shutdown, the server tries to finish all CherryPy server threads, by signaling them. However, if the application has other "user-defined" threads, the code fails.

```
2005/01/26 10:02:11 HTTP INFO <Ctrl-C> hit: shutting down
Unhandled exception in thread started by <bound method Thread.__bootstrap of <Thread(expireCache, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 451, in __bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 460, in __stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 256, in notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 238, in notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
```

In the example above, there is one extra thread that is started by the CacheFilter. It's a single thread, and it's set to run as a `Daemon`, so the server shutdown code doesn't need to worry about it. Neverthless, it tries to signal it and fail. In this case, the user thread is a single callable, and it does not support the same signaling protocol that is used by CherryPy itself to do the shutdown.

I believe that there are a few solutions for this problem:
- Server shutdown code doesn't have to worry about any other threads that are not CP core ones, and specially, 'daemonic' ones.
- Alternatively, the server shutdown code may try to signal all threads that 'conform' to the correct protocol, or that check the correct events.
- CherryPy can require that all user threads support a standard shutdown signaling protocols. (I believe that this is impossible to enforce in practice, though).

Reported by cribeiro

---
- Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/99

diff --git a/CHANGES.rst b/CHANGES.rst
index 23e5e830..d038e840 100644
--- a/CHANGES.rst
+++ b/CHANGES.rst
@@ -1,3 +1,9 @@
+v18.1.0
+-------
+
+* :issue:`1758` via :pr:`1759`: In the bus, when awaiting a
+  state change, only publish after the state has changed.
+
 v18.0.1
 -------
 
diff --git a/cherrypy/process/wspbus.py b/cherrypy/process/wspbus.py
index 8f762ef0..1f1d6577 100644
--- a/cherrypy/process/wspbus.py
+++ b/cherrypy/process/wspbus.py
@@ -375,7 +375,7 @@ class Bus(object):
 
         while self.state not in states:
             time.sleep(interval)
-            self.publish(channel)
+        self.publish(channel)
 
     def _do_execv(self):
         """Re-execute the current process.
['cherrypy/process/wspbus.py', 'CHANGES.rst']