情况是我有一个阻塞管道或套接字 fd，我不想write()阻塞，所以我先做了select()一个，但这仍然不能保证write()不会阻塞。
这是我收集的数据。即使select()指示可以写入，写入的PIPE_BUF字节数也会阻塞。然而，写入最多PIPE_BUF字节在实践中似乎不会阻塞，但POSIX 规范并未强制要求。
那只指定原子行为。Python(!) 文档指出：
报告为准备写入的文件
select()，poll()或此模块中的类似接口保证不会在写入最多PIPE_BUF字节时阻塞。POSIX 保证该值至少为512.
在下面的测试程序中，设置BUF_BYTES为100000在write()成功选择后在 Linux、FreeBSD 或 Solaris 上阻塞
。我假设命名管道与匿名管道具有相似的行为。
不幸的是，阻塞套接字也会发生同样的情况。通话
test_socket()中main()，并使用一个相当大的BUF_BYTES（100000好这里太）。目前尚不清楚是否有像PIPE_BUF套接字一样的安全缓冲区大小
。
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <limits.h>
#include <stdio.h> …是否传递指向cudaHostRegister的指针,该指针不是页面对齐允许/可移植的？我问,因为simpleStream示例执行手动页面对齐,但我在文档中找不到此要求.也许这是一个可移植性问题(类似于mlock()支持linux上的非对齐,但POSIX一般不会)？
我更改为带宽测试并使用非对齐,但注册的内存执行与cudaHostAlloc返回的内存相同.由于我使用这些固定缓冲区来重叠复制和计算,我也对非对齐是否阻止它(迄今为止我无法检测到性能损失)感兴趣.
我所有的测试都是在x86-64 linux上进行的.
使用驱动程序api可以排除在同一个应用程序中使用运行时api([1]).不幸的是,cublas,cufft等都基于运行时api.如果想要同时在cuModuleLoad和cublas中进行动态内核定义,有哪些选项？我记得这些,但也许还有更多:
A.等待计算能力3.5,传闻支持在同一个应用程序中驱动程序和运行时api的和平共存.
B.将内核编译为.so文件并将其删除.他们在dlcose上卸载了吗？
C.尝试从驱动程序api使用cuModuleLoad,但运行时api中的所有其他内容.不知道这是否有任何希望.
我没有屏住呼吸,因为jcuda或pycuda几乎是相同的绑定,他们可能已经想到了它.