You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm making a plugin to integrate Winpdb to CherryPy and I was having an issue with threads half-stopped on the block method of the cherrypy.engine (wspb) and it turns out that the problem is with a fix on cpython which set the _stop method body as pass and therefore never executing the expected method of the threading.Thread.
In particular this method sets the property: _is_stopped to True and because of that, the method threading.Thread.isAlive is unusable on the _DummyThread instances on Python 3.4. The problem was introduced after fixing the Issue 18808 of cpython the added a call to a new method _wait_for_tstate_loc that makes an assertion to the _is_stopped property and therefore ending with an AssertionError when the cherrypy.engine.block method reach the isAlive call.
After the isAlive call on the block method there is a comment which states:
Note that any dummy (external) threads are always daemonic.
And indeed is true, but the AssertionErrorgets raised before reaching that line on Python 3.4.
This is an example of the resulting traceback:
[03/Oct/2014:20:22:47] ENGINE Waiting for child threads to terminate...
Traceback (most recent call last):
File "/usr/lib64/python3.4/runpy.py", line 170, in _run_module_as_main
File "/usr/lib64/python3.4/runpy.py", line 85, in _run_code
File "/home/joe/repos/arrive/arrive/devserv/__main__.py", line 102, in <module>
File "/home/joe/repos/arrive/arrive/devserv/__main__.py", line 98, in main
File "/home/joe/repos/arrive/arrive/devserv/__main__.py", line 82, in run_with_debugger
File "/home/joe/env/arrive/lib/python3.4/site-packages/cherrypy/process/wspbus.py", line 335, in block
File "/usr/lib64/python3.4/threading.py", line 1119, in is_alive
File "/usr/lib64/python3.4/threading.py", line 1075, in _wait_for_tstate_lock
I suggest that we can change the isinstance validation of the _MainThread to:
I have come across the same kind of problem, but have a different solution.
I am using Windows 7 x64 with Python 3.5.1, Cherrypy 4.0.0. The same issue will occur whether cherrypy is run from the console and inside of a service.
In a clean virtualenv, the problem does not appear until pywin32 is installed. It happens with both the Pypi "pypiwin32-219" wheel, and the "pywin32-220" wheel from http://www.lfd.uci.edu/~gohlke/pythonlibs.
Steps to reproduce:
create a python virtualenv
activate the virtualenv
pip install cherrypy
pip install pypiwin32 or download and install the pythonlibs pywin32-220-cp35-none-win_amd64.whl
start a server using quickstart
send a keyboard interrupt (Ctrl+C)
observe crash & Traceback as above.
These are the commands to set it up, if your Windows is rusty.
If it doesn't happen the first time, start the server then try kicking off some threads by opening a browser and hitting 127.0.0.1:8080 a few times.
The problem goes away if the t.isAlive() check mentioned in the Traceback is removed, as follows:
cherrypy/process/wspbus.py line 332 in block()
325 for t in threading.enumerate():
326 # Validate the we're not trying to join the MainThread
327 # that will cause a deadlock and the case exist when
328 # implemented as a windows service and in any other case
329 # that another thread executes cherrypy.engine.exit()
330 if (
331 t != threading.currentThread() and
332 - t.isAlive() and
333 not isinstance(t, threading._MainThread)
This check to see if the thread is alive is not needed anyway, since from Python 2.6 to 3.5 , , the docs note that "The module function enumerate() returns a list of all alive threads". The objects being evaluated are from the enumerate call on line 325.
After making this change, the same sequence of steps results in successful shutdown, with the final log message "ENGINE Bus EXITED".