一个多CPU服务器正在运行几个进程。 一个进程有一个线程，应该始终处于空转状态，使用100％的CPU分配。 我当前的方法（除了要求开发人员…）是在等待信息到达它的打开的文件描述符，并使用recvfrom(2)连续检查它的erno设置为EAGAIN和方法返回-1当没有数据包要从networking套接字读取时。
我不是很舒适的追溯生产设置，这是一个很好的方式来确定这个信息。 我正在探讨proc(5)并认为/proc/[pid]/fdinfo flags字段的值可能对检查该进程是否使用带有O_NONBLOCK模式的open(2)套接字非常有用。
目前我正在努力扭转这个价值。 我知道它代表文件状态和文件模式的按位或。 所以我想我可以检查源标题的常量open(2)在该特定的内核使用的值，然后按位或他们，直到我find一个值匹配什么在fdinfo 。 这似乎相当笨重，如果任何人都可以validation上述方法（我还不能）或提供一个更优雅的解决scheme，我会非常感激。
我也知道fnctl(2)可以将一个文件描述符设置为非阻塞状态，但是我正在处理相当于打开的时刻
是的，这是检查套接字是否阻塞的有效方法。
非阻塞套接字的值是04000， /proc/<pid>/fdinfo中的非阻塞套接字以八进制表示。
你可以用pythonvalidation这个行为。
Python 2.7.5 (default, Feb 19 2014, 13:47:28) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> import os >>> from os import O_NONBLOCK >>> s = socket(AF_INET, SOCK_STREAM) >>> s.setblocking(0) >>> print open("/proc/self/fdinfo/{0}".format(s.fileno())).read(4096) pos: 0 flags: 04002 >>> if 04002 & O_NONBLOCK: ... print "yes" ... else: ... print "no" ... yes
所以，现在你知道了，我必须指出你的开发者做错了 。 如果非阻塞套接字是他们想要使用的，那很好 – 但是他们应该在套接字上设置一个epoll(2)而不是轮询。
程序在read(2) 没有得到一个产生EAGAIN非阻塞套接字 – 事实上，结果会更糟糕，因为几乎所有的系统调用都是一个抢占点，内核可以上下文切换。
这个开发者正在浪费电力，可以用于闲置线程的CPU周期，实际上并没有从这样做中获得任何好处。
如果开发人员想要“高速caching线”友好，把他的任务固定在一个特定的CPU上，并完成它。