我有一个父进程,它创建2个服务器套接字并调用它们上的select()
以等待新连接。当连接到达时,一条消息被发送到子进程(在创建服务器套接字之后用fork()
创建,以便共享它们)。在
在此子级中,在服务器套接字上调用accept()
不起作用。我得到一个EAGAIN
错误(非阻塞套接字)。而在主进程中调用accept()
工作得很好。在
当然,我根本不在主进程中调用accept()
,我只是测试它是否有效,它确实起作用了。在
为什么我不能在父进程中的select()
之后调用子进程中的accept()
?在
编辑:这里的目标是创建固定数量的worker(假设8个)来处理客户端连接,就像prefork模型中那样。这些连接将是长连接,而不像HTTP。其目标是平衡工作人员之间的连接。在
为此,我使用一个共享内存变量,该变量为worker包含当前连接的客户端的数量。我想“请求”客户端数量最少的工作人员处理新连接。在
这就是为什么我在父进程中执行select()
,然后向子进程发送消息,因为我想“选择”哪个进程将处理新连接。在
服务器监听多个套接字(一个用于ssl,一个没有),这就是为什么我在子进程中使用select()
而不是直接使用accept()
,因为我不能在我的子进程中的多个套接字上使用{
事实上,问题并不是我最初想的那样。下面是我在工作进程之间的连接的一些基本负载平衡方面所做的回顾。在
select()
accept()
(两者之间要使用的套接字在管道中传递,因此子进程知道要在哪个套接字上调用accept()
)问题是我的父进程告诉一个子进程接受套接字,然后立即重新进入循环,然后它再次运行
select()
。但是,如果子进程还没有接受套接字,select()
会再次返回同一个连接。这就是为什么我得到了一个EAGAIN错误,事实上我调用了accept()
两次(或者更多,取决于速度-进程间竞争条件)!在解决办法是等孩子回答管道上的问题,比如“嘿,我接受了连接,没关系!”,然后返回
select()
循环。在这个很好用。Python中的实现在这里提供给好奇的人:https://github.com/thibautd/Kiwi!在
相关问题 更多 >
编程相关推荐