问题描述
当我的python守护程序进程的asyncio run_forever循环侦听来自单独的run_until_complete asyncio协程（或线程）但在同一进程（PID）中运行的websocket调用时，我的python守护进程停止工作。更具体地说，我用Python 3.4.3编写了一个本地服务器，该服务器通过webbrowser函数更新了我的firefox webbrowser中的HTML网页。然后，我尝试捕获在临时弹出式窗口叠加层中引起的按钮按下，并通过websocket调用将相关的操作字符串中继回守护服务器。
My python daemon process stops working when its asyncio run_forever loop listens to websocket calls that originate from a separate run_until_complete asyncio coroutine (or thread) but runs within the same process (PID). More specifically, I code a localhost server in Python 3.4.3 that updates via the webbrowser function an HTML web page in my firefox webbrowser. I then try to capture button presses elicited in a temporary popup window overlay and relay the associated action strings via websocket calls back to the daemonized server.
一切正常，调用正常当websocket客户端调用来自通过命令行调用对同一python脚本进行调用的独立非守护进程PID时，在run_for_ever asyncio循环中嵌入的websocket服务器中进行了完美处理。当基于HTML GUI的websocket调用碰到run_for_ever asyncio循环时，对于websocket服务器，一切也可以正常工作。但是，当初始异步协程过程需要其他用户输入时（通过锁定的HTML窗口覆盖和诸如接受，取消或退出之类的按钮），从而试图捕获与按钮按下相关的websocket字符串信号，事情就出错了。通过简短的单独run_until_complete异步协程。
Things work fine and calls are processed flawlessly in the websocket server embedded in the run_for_ever asyncio loop when the websocket client call comes from an independent non-demonized PID invoked via a command-line call to the same python script. Things also work fine for the websocket server when an HTML-GUI-based websocket call hits the run_for_ever asyncio loop. But things go wrong when an initial asyncio coroutine process requires additional user-input - through a locking HTML window overlay and buttons such as 'accept', 'cancel' or 'quit' - and thereby attempts to capture the button press related websocket string signal through a brief separate run_until_complete asyncio coroutine.
换句话说，我试图找到一种方法来控制通过我的Python脚本的流，其中间歇性地有一个webbrowser-GUI用户输入是需要影响程序逻辑。
In other words, I try to find a way to control flow through my Python script where intermittently a webbrowser-GUI user-input is required to influence program logic. How can that be achieved in a pure Python solution ?
推荐答案
好，我找到了上述问题的解决方案，其中有两个更改：
ok, I found a solution for the problem described above, with two changes :
1）call_soon_threadsafe：该函数最终隔离了我的第二个异步循环，以便当调用以下行时，第一个异步循环得以幸存：
1) call_soon_threadsafe : this one finally 'isolates' my second asyncio loop so that the first asyncio loop survives when the following line gets invoked :
loop = asyncio.get_event_loop()
loop.call_soon_threadsafe( asyncio.async, websockets.serve( myFunct2, IP, PORT2))
loop.run_forever()
2）我为PORT2使用单独的数字作为HTML弹出窗口覆盖按钮websocket回调调用，它与第二个asyncio websocket循环相对应（请参见上文）。总之，常规的GUI回调与PORT1编号一起使用，而弹出的GUI调用与PORT2编号一起使用-为此临时创建了第二个asyncio websocket循环。
2) I use a separate number for PORT2 for the HTML popup overlay button websocket callback calls which corresponds with the second asyncio websocket loop (see above). In sum, regular GUI callbacks go with the PORT1 number, while the popup GUI calls go with the PORT2 number - for which the second asyncio websocket loop is created temporarily.
这篇关于使用asyncio websocket协程在HTML弹出叠加回调期间python守护程序服务器崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！