RuntimeError('threads can only be started once',)

Start at WebSocketPlugin.start and the websocket manager lifecycle shown in the report, then reproduce the failure by restarting the CherryPy server through runpy.run_module. Trace why the manager is started again after the first instance exits; done means websocket-enabled server restarts without the RuntimeError and without leaving the existing cleanup behavior broken.

Hi,
I am having this strange problem, I am writing tests on restarting a websocket enabled CherryPy server, and for some reason, when I by using runpy.run_module starts a new process instance, I get the "threads can only be started once"-error. But strangely, not in the first instance, which I am careful to properly clean up. Not sure how anything could be carried over to the new process, but I started barking up every tree in the end.

So this is the initialization:

1. I have these in the config for the relevant path:

       "tools.websocket.on": True,
       "tools.websocket.handler_cls": MessageWebSocket 
   

2. I start the engine like this, fairly conventional, I'd think:

   cherrypy._global_conf_alias.update(_web_config)
   WebSocketPlugin(cherrypy.engine).subscribe() # If I remove this row, CherryPy restart nominally
   cherrypy.tools.websocket = WebSocketTool()
   
   cherrypy.quickstart(_root, "/", _web_config)
   

3. And then I get this 'threads can only be started once', error in WebSocketPlugin, when it called start, I have added a condition there to just make it work for now, obviously that is not a long-term solution:

   def start(self):
       self.bus.log("Starting WebSocket processing")
       self.bus.subscribe('stop', self.cleanup)
       self.bus.subscribe('handle-websocket', self.handle)
       self.bus.subscribe('websocket-broadcast', self.broadcast)
       if not self.manager._started.is_set(): # this row added by me
           self.manager.start()
   

Any ideas? It seems very strange that only web socket would fail, could it be that it doesn't release something properly in the first process instance? Which has already called os._exit() by this time, and I get no issues with sockets kept open either.