本文主要是介绍IO端口复用之poll的底层实现，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
介绍
解说中存在一些函数和数据结构，具体出处可以参照上一篇关于select的分析 《IO端口复用之select的底层实现》，里面提及了一些储备知识点，本篇不再赘述。
由于tcp过于复杂，取个巧，全篇以udp连接来说明一下，内核版本依旧对应2.6.32。
poll系统调用做了什么
接口说明
poll系统调用接口，一共需要3个参数。
第一个参数是监听集指针ufds（struct pollfd结构类型指针），第二个参数是监听套接字的个数nfds（int类型），最后一个参数是超时事件timeout_msecs（long类型）。
内核中对ufds的定义是：
struct pollfd {
int fd;
short events;
short revents;
};
参数中使用了ufds变量，指向可以存储多个struct pollfd结构的空间，每一份struct pollfd就代表监听的一个套接字，其中的fd成员是套接字文件描述符值，该值理论上不受限制（不过每个进程自身的文件描述符数是受到限制的，再大也不能突破系统的限制，可通过ulimit -n查看，也可以进行修改）。既然ufds指向的是一块空间，理论上可以开辟出来nfds个空间来存储所有要监听的套接字信息，nfds也在理论上不受限制，不过受进程自身的描述符个数影响，可进行配置扩展。
此时，poll与select的第一个显著的不同点出来了，所监听的文件描述符个数是不同的，select限制在1024，而poll是根据进程的文件描述符限定值来确定的。
events用来描述期待监听事件的类型，可通过POLLIN、POLLOUT、POLLERR等进行或运算来赋值。revents代表对应套接字描述符的哪些事件已就绪。
此时，poll与select的第二个显著不同点也出来了，select预期监听集合和结果集合在应用层空间公用了一个，有监听的预期事件到来时，监听集就被拷贝成了结果集，select调用过程中fd_set得来回进行拷贝，而poll中使用了两个不同的变量events与revent来承接的。
内核代码追踪
sys_poll -> do_sys_poll
- 在do_sys_poll函数中，预开辟了空间stack_pps，其对应结构为struct poll_list类型，用head指针（struct poll_list *类型）指向stack_pps空间。stack_pps是为了承接poll函数传入的ufds，空间可能会不够。do_sys_poll函数在一个循环中，通过循环开辟空间walk（struct poll_list*类型），每次新开辟的walk包括若干个entries（struct pollfd结构），此处的若干个是通过min(剩余未拷贝个数，POLLFD_PER_PAGE)来确定的。并通过链表串联起来：例如head->next = walk。也就是说poll函数传递的参数依次拷贝到了以head为头节点的链表上，每个节点的结构都是struct poll_list类型，里面包括了若干个entries成员，len成员储存着entries的个数。
对比select会发现，select与poll都会开辟空间来存储对应的监听集合，只不过所采用的数据结构不太一样，poll函数稍微会浪费一些。
- 拷贝完成跳出for循环后，调用do_poll函数。do_poll函数的核心操作是一个循环体for(;;)，在主循环里面遍历所有的walk节点中的每一个entries对象pfd（struct pollfd类型指针），随后调用do_pollfd函数。
- 在do_pollfd函数中，通过fd得到对应的监听套接字的文件描述符file（struct file类型指针），随后调用f_op->poll函数，socket_file_ops中的poll函数为sock_poll。
- 在sock_poll函数中，通过file->private_data提取出来sock指针（struct socket结构指针）。而sock中的ops指向的是inet_dgram_ops，执行sock->ops->poll实际上调用了inet_dgram_ops中的poll函数udp_poll。
- 在udp_poll函数中，调用了datagram_poll函数，在datagram_poll函数中将在函数sock_poll_wait中调用__pollwait，在__pollwait中，将table结构中的entry(struct poll_table_entry结构)里面的wait作为挂载点，挂载到sk->sk_sleep中。在datagram_poll函数中，随后通过skb_queue_empty来判断sk的sk_error_queue(错误队列是否为空)，如果不为空则对mask置POLLERR。随后通过sk的sk_receive_queue是否为空，不为空则对mask置POLLIN。随后调用sock_writeable，通过sk->sk_sndbuf >> 1与sk->sk_wmem_alloc进行比较，如果缓冲区中剩余空间比发送缓冲区的一半还多，则可以继续进行发送，对mask置POLLOUT。
- do_pollfd将上述mask清除掉不需要的事件标记，赋值给对应的pfd中的revents成员。
- do_poll判断do_pollfd的返回值（返回mask），当有事件到来时，mask非0，使用count进行计数累加。
- do_poll随后会调用poll_schedule_timeout函数，并在poll_schedule_timeout中调用了schedule_hrtimeout_range函数，函数会将超时时间通过expires（ktime_t类型，既计算出来的总nsec数）。当超时时间值为0时，则设置当前进程状态为TASK_RUNNING，并返回0。当超时时间为NULL时，此时整个poll是所谓的阻塞状态，此时主动调用schedule进行进程调度，则设置当前进程状态为TASK_RUNNING，并返回-EINTR。后续通过hrtimer来判断阻塞时间，时间到了则返回0。
- 当返回0时候，do_poll函数中的timeout设置为1，意味着阻塞时间到或者无需阻塞。
- 在主循环体中，当time_out为1，或者count计数的值大于0时，或者当前进程有信号（signal_pending）需要处理时，do_poll都会跳出主循环体for(;;)返回。
小结
通过上述的流程总结，我们基本上对poll的所谓的轮训机制有了了解，这里的轮训并非单一的死循环，他对操作系统本身是没有太多的性能损耗，在永久阻塞或者超时模式下，都会主动进行schedule任务调度，即便使用NULL进行立即返回，我们在应用层处理的时候也是需要调用sleep或usleep来进行睡眠。
对比select和poll的底层实现可以发现，不考虑各自所能监听的套接字数量以及承接监听集合所开辟的空间大小，两者的轮训方式没有什么本质区别，在性能上也不会存在什么明显差异。
这篇关于IO端口复用之poll的底层实现的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
