既然每次调用select都要重新构建套接字集合，有FD_ZERO就足够用了，为啥还有FD_CLR ？

iw1210

linux_c_py_php 发表于 2013-02-28 14:22
代码里没做仔细, 应该在accept后判断fd是否<FD_SETSIZE, 不成立则close干掉连接, 另外应该select FD_SETSIZE而不是+1.

如果还用select，有没有解决办法？

yulihua49

iw1210 发表于 2013-02-28 14:16
回复 7# yulihua49

#define CONN_MAXFD FD_SETSIZE

是，已经改不加1了。
那个程序里的closeConnection的确可以不做FD_CLR的：

1. void closeConnection(connection_t conn)
   
2. {
   
3.     conn->using = 0;
   
4.     conn->woff = conn->roff = 0;
   
5.     close(conn->sock);
   
6.     fprintf(stderr,"tid:%lu %d closed\n",pthread_self(),conn->sock);
   
7. }
   

复制代码

iw1210

回复 22# yulihua49

现在新问题来了，见 linux_c_py_php 在 #11楼 提到的，怎么办？这关系的能否再继续用select做下去啊


   

linux_c_py_php

yulihua49 发表于 2013-02-28 15:34
是，已经改不加1了。
那个程序里的closeConnection的确可以不做FD_CLR的：

为何, 假设fd只发生了READ事件, 那么你的sched只移除了READ集合, 其他集合还是需要closeConnection在worker线程内做移除的.

yulihua49

iw1210 发表于 2013-02-28 15:22
如果还用select，有没有解决办法？

ulimit -n 1024
就不会出现这些问题。
不过要注意这是全部的fd，系统和应用还要打开部分文件都在这个数之内。

再不行就没办法了，如果select能解决一切问题，人们也就不玩epoll了。

linux_c_py_php

突然发现代码是不是有问题, 可读, 于是你只移除了可读然后把连接交给了worker, 然后接下来如果发生可写, 你又把连接交出去一次, 而前一次还没回来, 这样就完了.

sched里应该始终移除发生事件的3个集合.

yulihua49

linux_c_py_php 发表于 2013-02-28 15:49
突然发现代码是不是有问题, 可读, 于是你只移除了可读然后把连接交给了worker, 然后接下来如果发生可写, 你 ...

不可能的事，wfds没人设置，不会发生。

linux_c_py_php

yulihua49 发表于 2013-02-28 15:53
不可能的事，wfds没人设置，不会发生。

        pthread_mutex_lock(&beatLock);
        FD_SET(sock, &rfds);
        if (conn->woff > 0)
            FD_SET(sock, &wfds);
//      FD_SET(sock,&efds);
        pthread_mutex_unlock(&beatLock);

这里在worker里恢复读写, 假设这里有剩余数据待写, 下一次sched先触发了读, 然后进队列, 处理读(sendData正在操作buffer), 然后sched触发了写, 进队列, 处理写(也操作buffer)

yulihua49

linux_c_py_php 发表于 2013-02-28 15:57
pthread_mutex_lock(&beatLock);
        FD_SET(sock, &rfds);
        if (conn->woff > 0 ...

这个就要看linux_c_py...的程序了，考虑读写同时没？
一般的，这边没有写完，客户端是不会发来下一次的请求的。
除非是客户端主动关闭连接或被关闭，这也没问题。

iw1210

yulihua49 发表于 2013-02-28 15:47
ulimit -n 1024
就不会出现这些问题。
不过要注意这是全部的fd，系统和应用还要打开部分文件都在这个数 ...

用 ulimit 修改后，也就相当于把select 的 FD_SETSIZE 修改了么？