boost :: asio :: ip :: tcp :: resolver :: resolve() bloque pour toujours

Question

J'essaie de créer quelque chose de similaire à this code trouvé dans les exemples boost.asio.

socket.h:

class some_class { 
private: 
    ... 
     boost::asio::io_service io_service; 
public: 
     some_class() { 
      /* This stuff isn't used in the example... 
       ...but it doesn't change anything... */ 
      io_service.run(); 
     } 
}; 

socket.cpp:

using boost::asio::ip::tcp; 

bool some_class::connect(char* host, char* port) 
{ 
    printf("Resolving hostname...\n"); 

    /* Resolve hostname. */ 
    tcp::resolver resolver(io_service); 
    tcp::resolver::query query(tcp::v4(), host, port); 
    tcp::resolver::iterator iterator = resolver.resolve(query); 

    printf("Connecting to %s:%s... ", host, port); 

    /* Connect to resolved hosts. */ 
    sock->connect(*iterator); 

    return true; 
} 

g ++ construit ce sans aucune erreur, mais le code fait jamais passé l'appel resolver.resolve().
J'ai essayé "127.0.0.1" et "localhost" pour l'hôte et "80" pour le port. (ne pense pas que cela devrait avoir de l'importance, mais apache2 est opérationnel)

Quand je ctrl + c sort de mon application, il finit évidemment mais il sort le "Connecting to string" juste avant.

J'ai l'intention de construire l'exemple moi-même et de voir si le même problème se produit, et j'enverrai certainement les résultats ici. Quelqu'un at-il rencontré ce problème ou sait ce qui pourrait éventuellement provoquer ce comportement?

modifier:
L'exemple fonctionne très bien ... J'ai un peu de débogage à faire je suppose.

deuxième édition:
Je ne comprends pas, la seule chose qui pourrait être différente est hôte/port.
Exemple utilise char * argv [] et je l'utilise:

char host[] = "localhost"; 
char port[] = "80"; 

troisième édition:
il semble en effet être le blocage à la connexion, à fflush oublièrent (stdout). alors il doit y avoir un problème avec le socket. va faire un peu plus de tests.

quatrième édition:
stupide moi, ce n'était pas bloquant du tout! Je me reposais juste trop sur la sortie de console.

Answer 1

Il bloque probablement sur l'appel à relier, après le printf. Stdout est une ligne tamponnée par défaut, et comme vous n'avez pas de \ n à la fin de votre chaîne printf, vous ne verrez pas sa sortie. Lorsque vous tuez le programme, le tampon est vidé, c'est pourquoi vous voyez alors le message.