Python socketpair自定义实现中setblocking(False)的作用及平台相关疑问
嘿，这个问题问得挺到位的，我来给你拆解清楚：
为什么setblocking(False)能避免创建线程？
咱们先聚焦这段代码的核心目标：在单线程里造出一对已连接的套接字，模拟原生socketpair的效果。这个非阻塞的技巧，本质是为了绕开跨平台的单线程死坑。
你在Linux和新版Windows测试时代码能跑通，是因为现代系统的内核已经优化了同一进程内的TCP连接逻辑，但回到这个技巧的设计初衷——它要解决的是老系统里的死锁问题：
正常情况下，TCP三次握手是内核自动完成的，不需要用户调用accept()。但在旧版Windows这类系统中，当客户端和服务器套接字属于同一个进程时，内核会“卡住”三次握手的最后一步：必须等用户态调用accept()把连接从内核队列里取出来，客户端的connect()才会真正完成。
如果用阻塞模式的connect()，麻烦就来了：在单线程里，你先调用csock.connect(...)，它会一直阻塞等待连接建立；但此时程序被卡死在这里，根本没机会执行后面的lsock.accept()——直接形成死锁，程序永远停在connect()这一步。
而把csock设为非阻塞模式后，connect()会立刻抛出BlockingIOError（或InterruptedError），咱们忽略这个错误就行，然后马上就能执行lsock.accept()。等accept()拿到连接，内核的三次握手就彻底收尾了，再把csock切回阻塞模式，这一对套接字就正常可用了。
这就是注释里说“不用创建线程”的原因：如果不用这个非阻塞技巧，你就得开两个线程——一个跑connect()，一个跑accept()，才能避免互相阻塞。现在用这个小技巧，单线程就能搞定所有流程。
平台相关的边缘场景
你测试时没出问题，是因为现代Linux和新版Windows的内核已经改进了同一进程内的连接处理：内核会自动完成三次握手，哪怕你还没调用accept()，阻塞的connect()也能正常返回，不会卡死。
但在以下场景中，去掉setblocking(False)肯定会出问题：
- 旧版Windows系统：比如Windows 7及更早版本，TCP栈对同一进程内的本地连接逻辑就是要等
accept()触发，才会让connect()完成，阻塞模式下直接死锁。 - 特殊套接字配置：如果把监听套接字的
backlog设为0（代码里用的是默认值，但手动修改后就会出问题），内核不会缓存待处理的连接，connect()会一直阻塞到accept()被调用。 - 极端资源紧张的情况：当系统套接字资源耗尽时，内核处理连接的速度骤降，阻塞的
connect()可能会长时间挂起甚至假死，而非阻塞模式能让流程继续推进。
所以这个非阻塞的小技巧，本质是为了保证代码在不同平台和边缘场景下的可靠性，用处理少量异常的代价，换来了单线程下的跨平台兼容性，还不用引入线程的复杂度。
备注：内容来源于stack exchange，提问作者RSIMB GO
