À l'aide de boost::asio::ip::tcp::socket::annuler() et socket::close()

Si j'utilise la fermer et de ne pas annuler, il y a quelques problèmes.

La close fonction peut fermer le socket, et le solde des opérations asynchrones est arrêté par le retour boost::asio::error::operation_aborted erreur.

Pourquoi devrais-je utiliser cancel au lieu de close?

- Je m'inquiéter si certaines opérations asynchrones est en cours d'exécution, le cancel ne pouvait pas l'annuler, oui?

Comme asio::ip::tcp::resolve::cancel, j'ai essayer plusieurs fois pour annuler la resolve_handler après l'appel de async_resolve, mais resolve_handler retourne toujours avec pas de boost::asio::error::operation_aborted erreur.

Je pense que resolve_handler est en cours d'exécution?

Oui?

InformationsquelleAutor xiao su | 2011-06-22
  1. 6

    Annuler est utile si vous voulez arrêter les opérations en cours, sans fermeture de la socket.

    Noter que le Stimuler la documentation recommande l'utilisation de fermer pour une plus grande portabilité (à partir de la page de doc):

    ...
    Pour portable annulation, envisager de
    à l'aide de l'une des opérations suivantes
    alternatives:

    • Désactiver asio I/O port de fin d'
      backend par définition
      BOOST_ASIO_DISABLE_IOCP.
    • Utiliser le
      fonction close() simultanément
      annuler les opérations en cours et
      fermer le socket.
    • Toutefois, de noter les remarques pour annuler() également état Lors de l'exécution sur Windows Vista, Windows Server 2008, et plus tard, le CancelIoEx fonction est toujours utilisé. Cette fonction n'a pas de problèmes décrits ci-dessus.
    • merci à vous et Sam Miller pour obtenir de l'aide,je comprends un peu maintenant,merci
    InformationsquelleAutor holtavolt
  2. 6

    cancel de ne pas fermer le socket, donc à utiliser cancel si vous avez l'intention de continuer à utiliser le support de l'objet. En particulier, si vous disposez d'un code asynchrone méthodes de gestionnaire qui fait référence à la prise de fonctions de membre, vous ne voulez pas fermer le socket jusqu'à ce que vous êtes certain que votre actuellement en cours d'exécution asynchrone des gestionnaires d'avoir terminé.

    cancel ne garantit rien sur cours d'exécution asynchrone des gestionnaires, il garantit seulement (par la poussée de la documentation), que "Cette fonction provoque l'encours asynchrone connecter, envoyer et recevoir des opérations pour terminer immédiatement" dans le cas de la socket::cancel() appel, ou "Cette fonction les forces de l'achèvement de toutes les opérations asynchrones en attente sur l'ordinateur hôte résolution" dans le cas de la resolver::cancel() appel. Cette "achèvement" signifie que boost appelle votre gestionnaire asynchrone de la méthode, il n'a pas compétence pour injecter toute annulation logique dans votre gestionnaire asynchrone (sans oublier qu'il ne connaît pas le gestionnaire de mise en œuvre pour commencer).

    Je suggère l'ajout de votre propre logique dans votre gestionnaire asynchrone de la méthode pour gérer le cas où le support/résolveur/etc. est annulé. Si vous appelez la méthode cancel, alors vous avez probablement avoir la capacité de communiquer de cette annulation, le gestionnaire asynchrone de la méthode.

    • holtavolt est correcte, en utilisant close() n'est plus portable, mais tout dépend de ce que vous essayez de faire.
    • je vous remercie pour votre aide,oui,j'ai créer plusieurs objets à traiter la requête http et de mettre ces objets dans un std::deque,une tâche à venir,pop_front un objet à partir de deque au travail,lors de l'arrivée push_back l'objet d'deque,quand quelque chose d'erreur lors de la connexion,envoyer ou de lire,je vais fermer le socket,mais dans se connecter et lire,j'ai mis une 20s délai d'attente,lorsque le délai de connexion,je veux annuler le rappel func handle_connect,dans ce handle_connect_timeout ou handle_read_timeout,je ne suis pas sûre de l'utiliser,de l'annuler ou de le fermer,mais maintenant ,je pense que le mieux pour moi est proche
    InformationsquelleAutor devyndraen