套接字应该是非阻塞的才能与 Python 中的 select 一起使用吗？
- 与
select.select 一起使用时，套接字是否应设置为非阻塞在 Python 中？ - 如果它们是或不是，有什么区别？
有时我发现调用 send 将阻塞。此外，我发现阻塞套接字通常会发送整个给定缓冲区 (128 KiB)。在非阻塞模式下，发送将接受少得多的字节（与前面给出的示例相比为 20-40 KiB）并且返回速度更快。我正在使用 Lucid 上的 Python 3.1。
- Should sockets be set to non-blocking when used with
select.selectin Python? - What difference does it make if they are or aren't?
Occasionally I find that calling send on a socket that returns sendable will block. Furthermore I find that blocking sockets will generally send the whole buffer given (128 KiB). In non-blocking mode, sending will accept far fewer bytes (20-40 KiB compared with the example given earlier) and return quicker. I'm using Python 3.1 on Lucid.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不幸的是，答案可能取决于操作系统。我只回答有关Linux的问题。
我不知道 select 中阻塞/非阻塞套接字的差异，但在 Linux 上，
select系统调用手册页的“BUGS”部分中有此内容：我怀疑上面的 python 抽象可以“隐藏”这个问题而不会产生副作用。
至于阻塞写入发送更多数据，这是预期的。如果套接字阻塞，
send将阻塞，直到有足够的缓冲区空间来传递整个请求。如果套接字是非阻塞的，则它仅发送套接字发送缓冲区当前可以容纳的内容。The answer might be OS dependent unfortunately. I'm replying only regarding Linux.
I'm not aware of differences regarding blocking/non-blocking sockets in select, but on linux, the
selectsystem call man page has this in it 'BUGS' section:I doubt a python abstraction above that could "hide" this issue without side-effects.
As for the blocking write sending more data, that's expected.
sendwill block until there is enough buffer space to pass your whole request down if the socket is blocking. If the socket is non-blocking, it only sends as much as can currently fit in the socket's send buffer.