@reaCodes 。。。。

proc1 = subprocess.Popen(...)
proc2 = subprocess.Popen(...)

我不懂你哪里不懂。。。

proc = subprocess.Popen(...)
proc.pid

不行嘛？

楼主第一个谬误：参考系 != 观察者。在相对论中不存在“观察者”这个概念（量子力学的争论关相对论什么事情）。两个人在不同参考系下都客观地在发生事件，只不过因为不存在全局时钟，所以如果你要把两个参考系下的事件放在一起做“同时性”讨论，就要做参考系的时钟变换罢了。

由此延伸出来，arch wiki 天下第一（这个我同意） = arch 易用性天下第一。

有些极端教徒甚至觉得，不会照着 wiki 敲命令配系统调 bug，不愿意折腾的，不配用 linux 。

@Jianrry 而且总有教徒觉得不提 PR 不帮忙解决 BUG 就没资格抱怨 Linux 桌面不好用。

@no1xsyzy 对呀，我上面的基本看法也是两个线程呀。我从来不觉得 GUI 用协程搞是好主意啊。

@no1xsyzy 我感觉吧，楼主这只是个 demo 。

GUI 调用协程是有实际价值的。譬如你用 requests，用线程池做下载器，并发才多少。用上 aiohttp，并发一下子暴涨。你只需要用 asyncio 的 queue （那个是线程安全的好像）把 task 塞进 asyncio 里面，最后在主线程通过 event 把结果弄回来就行了。

@no1xsyzy

1 、独占线程和 GIL 锁没有任何关系。一个 C 语言写的线程完全可以进入 while 之前释放 GIL 锁，在调用任何 python 函数之前获取 GIL 锁。tk 的 mainloop 是 C 模块。

搜了一下： https://github.com/python/cpython/blob/master/Modules/_tkinter.c#L2861

对于等待。确实 GUI 一般不是忙等待。像 Windows API 是调用操作系统的 API 获取下一个 event，而操作系统内部必然有队列，不是忙等待。比如

Windows： https://docs.microsoft.com/en-us/windows/win32/learnwin32/window-messages
xlib: http://mech.math.msu.su/~nap/2/GWindow/xintro.html

mac 没了解过，不过大概差不多，不然很难想象 Qt 那种库该怎么写，因为从上到下都充斥着 event-loop 的味道（比如别的线程要更新界面必须发送一个消息到 GUI 主线程）。所以你见过的不是 event loop 的 GUI 库（比如 Qt ）大部分情况下只是给你把操作系统的 eventloop 包装了一下而已。

@ppgs8903 你在说啥？完全牛头不对马嘴吧。。。

@Nich0la5 在 GUI 程序里面用 aio eventloop 没啥问题吧，用啥不能用。关键是楼主用错了。

- - - -

@gzlock

要理解 aio，其实最好去看一看 select/epoll 的资料。Python 的 async 语法只是一堆语法糖，本质就是让人写 eventloop 程序更容易。然后 GUI 又是一个典型的 eventloop，有兴趣可以看看 Windows API 写 GUI 的那套，或者看看 Qt 源代码。但不管是什么类型的 eventloop，都需要有一个 while loop 来 receive event -> process event 。

既然有两个 eventloop，那么自然需要两个线程去各自跑这两个 eventloop 。

asyncio.run() 就是跑那么一个 loop，内部我虽然没看过代码，但本质肯定等价于一个 while loop，直到所有协程跑完再退出。如果你在 gui 的 main thread 里面跑，就相当于阻塞了 gui 的 eventloop 。

aio eventloop 需要独占一个线程，GUI 也需要独占一个线程。所以你永远需要至少两个线程。

这种话在大部分码农工作的语境下都是鸡汤。码农工作学到的东西基本上五年以后就没用了不是么。