Windows Sockets: O bloqueio
Este artigo e dois artigos complementares explicam vários problemas na programação Windows Sockets.Este artigo aborda o bloqueio.Outras questões são abordadas nos artigos: Windows Sockets: byte pedidos e Windows Sockets: Convertendo strings.
Se você usar ou deriva da classe CAsyncSocket, você precisará gerenciar estes problemas sozinho.Se você usar ou deriva da classe CSocket, O MFC gerencia-las para você.
O bloqueio
Um soquete pode estar em "modo de bloqueio" ou "modo de não bloqueado". As funções de soquetes no modo de bloqueio (ou síncrono) não retornam até que ele podem concluir sua ação.Isso é chamado de bloqueio porque o soquete cuja função foi telefonar não é possível fazer qualquer coisa — é bloqueado — até que a telefonar retorna.Uma telefonar para o Receber função de membro , por exemplo, pode levar um time arbitrariamente para concluir aguarda o aplicativo de envio enviar (isso é se você estiver usando CSocket, ou usando CAsyncSocket com bloqueio). If a CAsyncSocket objeto está no modo não bloqueado (operacional assíncrona), a telefonar retorna imediatamente e o código de erro corrente, possam ser recuperado com o GetLastError função de membro , é WSAEWOULDBLOCK, indicando que a telefonar deve ter bloqueada tinha não retornar imediatamente por causa do modo.(CSocket nunca retorna WSAEWOULDBLOCK.A classe gerencia o bloqueio para você.)
O comportamento de soquetes é diferente em 32 bit e 64 bit operating systems (sistema autônomo Windows 95 ou Windows 98) que nos sistemas operacionais de 16 bit (sistema autônomo o Windows 3.1).Ao contrário de sistemas operacionais de 16 bit, os sistemas de operacionais 32 bit e 64 bit usam multitarefa preemptiva e fornecer multithreading.Nos sistemas operacionais de 32 bit e 64 bit, você pode colocar os soquetes em segmentos de trabalho separados.Um soquete em um thread pode bloquear sem interferir em outras atividades em seu aplicativo e sem gastar time de computação no bloqueio.Para obter informações sobre a programação multithreaded, consulte o artigo Multithreading.
.gif "Observação") Observação: |
|---|
Em aplicativos multissegmentados, você pode usar a natureza do bloqueio CSocket para simplificar o design do seu programa sem afetar a capacidade de resposta da interface do usuário. Manipulando as interações do usuário no thread principal e CSocket processamento em segmentos alternativos, você pode separar essas operações lógicas. Em um aplicativo que não é multithreaded, essas duas atividades devem ser combinadas e tratadas sistema autônomo um único segmento que normalmente significa usar CAsyncSocket Portanto, você pode manipular sistema autônomo solicitações de comunicações sob demanda ou substituindo CSocket::OnMessagePending para lidar com ações do usuário durante longa atividade síncrono. |
O restante deste debate é para programadores direcionamento de sistemas operacionais de 16 bit:
Normalmente, se você estiver usando CAsyncSocket, você deve evitar usar as operações de bloqueio e operar assincronicamente em vez disso. Em operações assíncrono, do ponto em que você recebe um WSAEWOULDBLOCK código de erro após chamar Receber, por exemplo, você aguardar até que o seu OnReceive função de membro é chamada para notificar que você pode ler novamente. Chamadas assíncrono são feitas por função de notificação de retorno de chamada apropriada do seu soquete, sistema autônomo, por exemplo, chamar de voltaOnReceive.
Em Windows, chamadas de bloqueio são consideradas uma prática inadequada.Por padrão, CAsyncSocket oferece suporte a chamadas assíncrono e você deve gerenciar o bloqueio por conta própria usando notificações de retorno de chamada. De classeCSocket, por Outros lado, é síncrono.Ele bombeia mensagens do Windows e gerencia o bloqueio para você.
Para obter mais informações sobre bloqueio, consulte a especificação de Windows Sockets.Para obter mais informações sobre como "On" funções, consulteWindows Sockets: Notificações de soquete e Windows Sockets: Derivando de Classes Socket.
Para obter mais informações, consulte: