# 18.3 Socket标记 Socket的行为可能随着创建时指定的不同而有很大的差异,下表列出了Socket可以指定的标记: | wxSOCKET_NONE | 普通行为(行为和底层的send和recv函数一致). | |:--- |:--- | | wxSOCKET_NOWAIT | 读和写操作尽可能快速的返回. | | wxSOCKET_WAITALL | 等待所有的读写数据完成操作,除非出现系统错误. | | wxSOCKET_BLOCK | 在读写数据的时候阻塞GUI界面. | 如果没有指定任何标记(或者指定了wxSOCKET_NONE标记),I/O操作将在部分数据被读写的时候返回,甚至在整个数据还没有传输完的情况下也是这样.这和使用阻塞方式调用底层的recv或者send函数的效果是一样的.注意这里所说的阻塞指的是函数被阻止返回,并不意味着图形用户界面被冻结. 如果指定了wxSOCKET_NOWAIT标记,I/O将立刻返回.对于读操作,它将读取所有当前输入缓冲区拥有的数据后立刻返回,对于写操作,它将尽可能多的发送数据以后立刻返回,这取决于当前的输出缓冲区的大小,这种方式等同于使用非阻塞方式调用底层函数recv或send.同样, 这里的阻塞也指的是函数返回,而不是用户界面阻塞. 如果指定了wxSOCKET_WAITALL标记,I/O操作将在所有要求的数据被读取或者被写入以后(或者发生系统错误)才会返回. 如果需要的话,将以阻塞的方式调度底层系统函数.这相当于使用一个循环重复以阻塞的方式调用recv或者send函数以便传输所有的数据.同样,这里的阻塞也指的是阻塞底层函数而不是GUI.注意ReadMsg和WriteMsg函数将隐式使用这种方式,并且忽略你可能设置的wxSOCKET_NONE或 wxSOCKET_NOWAIT标记. 用来指示wxSOCKET_BLOCK是否在I/O操作的间隙执行Yield操作(译者注:参见前面关于线程的替代方案中的描述),如果指定了这个标记,socket在底层操作间隙将不会执行Yield动作,反之,如果没有指定这个标记,那么你要非常小心这可能产生的代码重入的问题. 总的来说: * wxSOCKET_NONE 总是试图读取或者写入一些数据,但是不关心具体是多少数据. * wxSOCKET_NOWAIT 只关心尽快返回,即使没有读取或写任何数据. * wxSOCKET_WAITALL 将在所有的数据都被写入或者是读取的数据达到要求的数目的时候返回. * wxSOCKET_BLOCK 和前面的标记没有关系,只控制否则在底层操作的间隙执行Yield动作. wxWidget中的阻塞和非阻塞socket 在wxWidgets中的阻塞方式有双重的含义.在一般的编程中,socket阻塞意味着当前的线程被挂起直至socket操作超时或者数据操作完成.如果是主线程阻塞,则用于界面也相应阻塞. 而在wxWidgets中,有两种类型的阻塞:socket阻塞和用户界面阻塞.wxSOCKET_BLOCK标记指示在socket阻塞的时候,是否同时阻塞用户界面.你也许回问,这怎么可能呢,怎么可能作到阻塞了socket操作而不阻塞用户界面呢?这主要是因为在socket被阻塞的时候,wxWidgets还可以处理所有的事件,因为socket的底层函数处理的间隙调用了wxYield,这个函数可以处理队列中所有未处理的事件,包括用户界面相关的事件.虽然在socket操作未结束之前,代码一直在socket函数中运转,但是所有事件还是可以被有序的处理. 对于刚开始使用wxWidgets的人来说,听上去这是一个很美妙的事情.如果你是第一次使用wxWidgets进行socket编程,你可能会觉得,再也不需要使用任何单独的线程来处理socket了,你可以将socket设置为wxSOCKET_WAITALL和 wxSOCKET_BLOCK,这样你可以通过事件机制处理socket数据,而GUI也不会被阻塞,不幸的是,我必须先警告你,这种想法可能是你痛苦的开始. 让我们来假设一个服务端有两个活动连接,每一个都设置了wxSOCKET_WAITALL标记.更进一步,我们假设其中一个连接正在以一种很缓慢的速度传输一个很大量的数据.Socket 1的读缓冲区没有数据了,因此它调用了wxYield,而Socket2还有未处理的事件在队列里,这时候会发生的事情是:Socket1调用的 wxYield试图处理Socket2相关的消息,但是因为Socket2的连接很缓慢,它的事件总是结束不了,它也会调用wxYield来避免GUI阻塞,这将导致出现一个名声不太好的告警消息"wxYield called recursively"(wxYield被递归调用),在Socket2的数据传输结束之前,应用程序的堆栈将最终被wxYield的递归调用给耗尽, 因为递归调用使用这些堆栈一直没有机会释放,于是人们开始联系wxWidgets社区,报告发现了一个bug,而实际上,这应该是应用程序自己的问题而不是wxWidgets的问题.应用程序不应该以这种方式来编程,它应该避免这种情形出现,因此,恐怕wxWidgets永远没有办法改正这个问题. 另外一方面,性能也是一个问题,为了不阻止GUI,你的应用程序将不得不浪费CPU的资源.试想一下,用户界面要立即响应, Socket也要不停的监视是否有数据到来以便产生事件通知应用程序,要让两者都得到满足,wxWidgets所能做的唯一的办法就是使用循环,不停的以非阻塞的方式去用系统操作select去测试socket,然后再调用wxYield处理GUI事件. 不可用的标记组合 容我再罗嗦一句,不要天真到认为wxWidgets采用了一种神奇的socket处理机制.无论这些Socket的标记在你的第一印象中看起来是多么的诱人,你都不可能同时满足下面的这些要求: * wxSOCKET_WAITALL * 不阻塞GUI * 少于100%的CPU占用率 * 单线程 你可以指定wxSOCKET_WAITALL并且也不阻塞GUI,但是这将导致100%的CPU占用率.如果你愿意付出阻塞GUI作为代价(指定 wxSOCKET_BLOCK标记),你将可以得到wxSOCKET_WAITALL和0%的CPU占用率. 或者你可以使用多线程来实现同时使用wxSOCKET_WAITALL又不阻塞GUI,并且也不用100%的CPU占用率.你也可以不用 wxSOCKET_WAITALL而使用wxSOCKET_NOWAIT以便可以既不占用100%的CPU又不堵塞GUI.总之一句话,上面的四个条件, 你总可以同时满足任意三个,但是你不可以四个条件同时满足. 这些标记是怎样影响Socket的行为的 wxSOCKET_NONE, wxSOCKET_NOWAIT和wxSOCKET_WAITALL是互斥的,你不可以同时使用他们中间的任何两个,而wxSOCKET_BLOCK和 wxSOCKET_NOWAIT的组合也是没有意义的 (如果任何函数都立即返回,怎么可能阻塞GUI呢?), 因此下面五种标记的组合是有意义的: * wxSOCKET_NONE | wxSOCKET_BLOCK: 这种组合和标准的socket调用(recv和send)的行为相同. * wxSOCKET_NOWAIT: 和标准的非阻塞的socket调用行为相同. * wxSOCKET_WAITALL | wxSOCKET_BLOCK: 和普通的阻塞式socket调用的行为相同,只不过recv和send函数将被连续多次调用以便接受或者发送完整的数据. * wxSOCKET_NONE: 和标准的socket调用行为相同,只是由于在完成系统调用之前(比如数据完整接收缓冲区数据之前)调用了wxYield,因此看上去GUI并不会阻塞. * wxSOCKET_WAITALL: 和wxSOCKET_WAITALL | wxSOCKET_BLOCK的行为相同只不过GUI将不被阻塞. 只有最后两种情况可能出现前面介绍的wxYield函数重入的问题,不过这俩组标记也是在wxWidgets中基于事件的socket编程中最主要的两种方式(因为他们阻塞了socket但是却不阻塞GUI).使用这两组标记的时候要非常小心避免这个问题,虽然它们很强大,很有用,却也往往是错误和麻烦的根源,因为它们太容易被误解了. 标准socket和wxSocket 使用wxSOCKET_NONE | wxSOCKET_BLOCK或wxSOCKET_NOWAIT的时候和直接使用socket系统调用的效果并没有不同,唯一的不同是你使用的是 wxWidgets提供的API而不是标准C的API.不过,即使这样,还是有足够的理由要使用wxSocket,这些理由包括:wxSocket提供了一个面向对象的接口,隐藏了很多平台相关的初始化代码,还提供了一些高级的函数比如WriteMsg和ReadMsg.另外,下一节我们也将看到, wxSocket也使我们可以用流的方式来操作socket.