所有的socket消息入口只有一个线程，而且是单线程:void EventThread::Entry().
这个线程不断地遍历所有注册到窗口的socket消息（每一个新的socket，注册到窗口的消息id不同).
此处的单线程循环处理所有客户端的消息，是否能达到高性能，个人感觉不能（上百万客户端，仅仅靠单线程捕获消息） 。
当消息到达后，在EventThread中仅仅是调用了一个耗时极短的函数：ProcessEvent。
在EventContext中，该函数将任务放到taskthread队列中（让线程池去处理消息），后直接返回。
事实上，通过调试发现，EventThread线程获监听的消息绝大多数为：FD_READ | FD_ACCEPT | FD_CLOSE，对于
其他消息如：FD_WRITE的消息是很少去注册，直接发送数据到客户端即可。想想也是，rtsp流媒体服务器，不会主动发消息给客户端，都是
接收到FD_READ消息后，去响应该消息而将数据发送给客户端。FD_WRITE消息很少注册将大大降低EventThread线程的工作压力，
当多个客户端同时从服务器上接收rtsp流时，EventThread线程压力很低，因此此过程中读消息(FD_READ | FD_ACCEPT | FD_CLOSE)
很少发生。
但是当有多个rtsp推流器，将数据流推送到darwin服务器上时，服务器将频繁的收到FD_READ消息，因此压力会很大。服务器同时支持多少个推送客户端推送rtsp数据流，需要进一步测试。
模拟一个rtsp推流器，推送视频流到darwin服务器上，相当于一个客户端一直往服务器上发送窗口消息（消息id相同），如下所示，服务器会一直收到窗口消息id为1036的socket数据流。