Windows Sockets: bloqueando
Este artigo e dois artigos complementares explicam vários problemas na programação de soquetes do windows. Este artigo abrange o bloqueio. Outros problemas são abordados em artigos: Soquetes do windows: A ordenação de bytes e Soquetes do windows: Convertendo cadeias de caracteres.
Se você usar ou se deriva da classe CAsyncSocket, você precisará gerenciar esses problemas você mesmo. Se você usar ou se deriva da classe CSocket, o MFC gerenciá-los para você.
Bloqueio
Um soquete pode estar no modo de bloqueio” ou “o modo nonblocking”. As funções de soquetes no modo de bloqueio (síncrono) ou o não retornam até que possam terminar sua ação. Isso é chamado de bloqueio porque o soquete cuja função for chamada não pode fazer nada — — será bloqueado até que a chamada retorna. Uma chamada à função de membro de Receber , por exemplo, arbitrariamente pode levar muito tempo para terminar enquanto aguarda o aplicativo que envia enviar (é se você estiver usando CSocket, ou usando CAsyncSocket com bloqueio). Se um objeto de CAsyncSocket está no modo nonblocking (que opera de forma assíncrona), a chamada retorna imediatamente e o código de erro recuperável atual, com a função de membro de GetLastError , é WSAEWOULDBLOCK, indicando que a chamada bloquearia o não tivesse retornado imediatamente devido ao modo. (CSocket nunca retorna WSAEWOULDBLOCK. A classe gerencia o bloqueio para você.)
O comportamento de soquetes é diferente em sistemas operacionais de 32 bits e de 64 bits (como o Windows 95 ou Windows 98) do que em sistemas operacionais de 16 bits (como o Windows 3.1). Diferentemente dos sistemas operacionais de 16 bits, os sistemas operacionais de 32 bits e de 64 bits usam a diversos - tarefa preemptivo e fornecem a multithreading. Nos sistemas operacionais de 32 bits e de 64 bits, você pode colocar seus soquetes threads de trabalho separados. Um soquete em um thread pode bloquear sem interferir com outras atividades em seu aplicativo e sem passar tempo de cálculo no bloqueio. Para obter informações sobre a programação multi-threaded, consulte o artigo Multithreading.
Dica
Em aplicativos multithreaded, você pode usar a natureza de bloqueio de CSocket para simplificar o design de programa sem afetar a capacidade de resposta da interface do usuário.Tratando interação do usuário no thread principal e em CSocket que processam threads alternativa, você pode separar essas operações lógicas.Em um aplicativo que não é de vários threads, essas duas atividades devem ser combinadas e é tratado como um único thread, que geralmente as mídias usando CAsyncSocket para que você possa lidar com as solicitações de comunicações sob demanda, ou substituir CSocket::OnMessagePending para tratar ações do usuário durante a atividade síncrono longa.
O restante desta discussão é para programadores que visam sistemas operacionais de 16 bits:
Normalmente, se você estiver usando CAsyncSocket, evite usar operações de bloqueio e operar de forma assíncrona em vez disso. Nas operações assíncronas, do ponto em que você recebe um código de erro de WSAEWOULDBLOCK depois de chamar Receber, por exemplo, você espera até que a função de membro de OnReceive seja chamada para notificá-lo que você pode ler novamente. As chamadas assíncronas é feito chamando a função backup apropriado de notificação de retorno de chamada do soquete, como OnReceive.
Nas janelas, bloqueando chamadas são considerados prática incorreto. Por padrão, CAsyncSocket da suporte a chamadas assíncronas, e você deve gerenciar o bloqueio você mesmo que usa notificações de retorno de chamada. A classe CSocket, por outro lado, é síncrono. Bombeia mensagens do windows e gerencia o bloqueio para você.
Para obter mais informações sobre bloqueios, consulte a especificação de soquetes do windows. Para obter mais informações sobre as funções de " ON ", consulte Soquetes do windows: Notificações de soquete e Soquetes do windows: Derivação das classes de soquete.
Para obter mais informações, consulte: