0

使用https://pypi.org/project/cproto/，附加到在 Docker 容器中无头运行的 Chrome 上，我发现它有时会卡住（下面引用的示例不可靠 - 您可能需要运行它几次）：

$ python3
Python 3.6.8 (default, Jan 14 2019, 11:02:34) 
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cproto
>>> cp = cproto.CProto()   # localhost:9222 == my Chrome container
>>> cp.close()
>>> exit()
^CException ignored in: <module 'threading' from '/usr/lib/python3.6/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 1294, in _shutdown
    t.join()
  File "/usr/lib/python3.6/threading.py", line 1056, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
$

这也发生在 Chrome 正常运行时，带有一个 UI，在 Docker 之外。

不管 Chrome 可能会处理什么讨厌的事情，cproto 库应该像这样陷入困境似乎有点“离题”。

有没有办法强制退出cproto？ （我在上面做错了什么，还是这是一个错误？）

4

1 回答 1

1

看起来一些非守护线程在主线程退出后仍在运行。这项工作对我有用（尚未找到根本原因，需要更多调查）：

diff -ur cproto.orig/core/websocket.py cproto/core/websocket.py
--- cproto.orig/core/websocket.py       2021-01-04 01:24:53.000000000 +0000
+++ cproto/core/websocket.py    2021-03-10 04:10:32.228436532 +0000
@@ -38,8 +38,16 @@
     def connect(self, *args, **kwargs):
         super(self.__class__, self).connect(*args, **kwargs)
 
-        threading.Thread(target=self._read_messages).start()
-        threading.Thread(target=self._process_events).start()
+        # threading.Thread(target=self._read_messages).start()
+        # threading.Thread(target=self._process_events).start()
+
+        t1 = threading.Thread(target=self._read_messages)
+        t1.setDaemon(True)
+        t1.start()
+
+        t2 = threading.Thread(target=self._process_events)
+        t2.setDaemon(True)
+        t2.start()
 
     def close(self):
         # Terminates blocking `get` call on events processing thread
于 2021-03-11T03:59:24.660 回答