对二手交易已经是随缘的态度了。。在闲鱼被某些买家恶心久了。。谈得来的就卖。谈不来的喷一下直接拉黑 XD

可以不用 MSYS 或者 Cygwin 了

xfce 需要安装 pulseaudio

@bernardx
P2715Q 用户，凑上去看确实比不了 rmbp 的屏，但是除非凑上去看，否则看不出区别

@iMouseWu
while 1
{
ready_set = select(fd_set)
for item in ready_set
if item is listen_sock
client_sock = accept(listen_sock)
fd_set.append(client_sock)
else
buf = read(item)
}

大致这样子

@iMouseWu
我理解错你的意思了，我以为你说的是客户端进行 accept

server 监听一个 listen socket ，每次 accept 会产生一个 client socket
使用 IO multiplexing 的时候，将 listen socket 和每次 accept 产生的 client socke 都添加到监听集合中
除此之外， io multiplexing 也可以监听 timerfd ， eventfd 等，用于监听计时器事件和计数器事件

@iMouseWu 客户端出于什么情况需要 accept 呢? :)

@mhycy 谢谢，这个问题我确实不太了解

proxychains

再插一句， epoll 在 ET 模式下的饥饿问题是类似原因

@DuckJK V2 的回复不能直达楼层好蛋疼。。。

IO multiplexing 在使用的时候必须配合应用层的 buffer ，这是 TCP 的本质决定的， TCP 是一个字节流协议，没有包的概念，不能保证你每次 read 读到的都是一个完整的『应用层的包』，因此通常人们使用类似 readn, readline, readUntil 这类函数来处理 socket 读

在 IO multiplexing 的场合下，针对 blocking sockets 使用这类函数显然是不科学的，如果你希望读到一个 1024bytes 的应用层包，而 socket 上只有 512bytes 数据，那么整个 IO 线程就阻塞了,直到读满了 1024bytes ，科学的做法是 socket 里面有多少数据就读多少，读出多少就写进应用层 buffer ，应用层再从 buffer 里面读应用层的包，上层的应用逻辑通过 buffer 和 TCP 打交道，这和 non-blocking socket 的处理模式是一样的，也就是我在上面说的『在其他场合可以使用 non-blocking sockets ，但不会带来任何好处』

@iMouseWu IO multiplexing 和后续的并发处理是完全不相关的两件事， select 出一个 fd 以后，是当场处理还是丢到线程池里面处理，还是用更加猥琐的回调+协程方式去处理都是有可能的，这属于并发处理的范畴

IO Multiplexing 的意义在于提供了一种机制让你可以同时监听大量 socket
对于 blocking sockets, 显然你直接去尝试 read 是不可行的，因为不知道会阻塞在哪儿
对于 non-blocking sockets ，不用 io multiplexing 的话，就只能通过 busy polling 去探查 socket 是否可读，这也是不太能接受的做法

@DuckJK 你举出的那种情况是客观存在的，网卡收包以后会通过驱动通知相关的 socket ，但是如果后续发现是错包的话会将这个包丢掉，然而 io multiplexer 已经发出了 fd 可读事件，这时候使用阻塞读会造成阻塞，但是这应该是几率很低的一种情况，我个人觉得不具有说服力。

我的理解中，必须使用 non-blocking socket 的情况只有 epoll 的 ET mode

IO multiplexing 在某些情况下必须搭配 Non-blocking socket 使用，在另外一些情况下可以使用 Blocking Sockets ，但不会带来任何好处，也不会降低编程的复杂度

2 年经验+没啥干货的 blog+职位期望架构师。。。其实人家是给楼主吓到了吧。。。虽然对这个公司也挺有好感的。。