boost :: asio :: ip :: tcp :: resolver :: resolve () blocos para sempre

Question

Eu estou tentando criar algo semelhante como este código encontrados nos exemplos 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 ++ constrói este sem erros, mas o código nunca faz com que seja passado a chamada resolver.resolve ().
Eu tentei tanto "127.0.0.1" e "localhost" para o anfitrião e "80" para a porta. (Acho que não deveria importar, mas apache2 está instalado e funcionando)

Quando eu Ctrl + C para fora do meu aplicativo, ele obviamente termina, mas ele faz a saída do "Ligar a string" pouco antes de ele faz.

Estou pensando em construir o exemplo me e ver se ocorre o mesmo problema, e vai certamente postar os resultados aqui. Alguém já encontrou este problema ou sabe o que poderia possivelmente causar este comportamento?

edit:
O exemplo funciona muito bem ... Eu tenho alguma depuração para fazer suponho.

segunda edição:
Eu não obtê-lo, a única coisa que poderia ser diferente é host / port.
Exemplo usa carbonizar argv * [] e eu estou usando:

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

terceira edição:
ele realmente parece estar bloqueando a conexão, se esqueceu de fflush (stdout). então ele tem que ser um problema com o soquete. vai fazer mais alguns testes.

quarta edição:
me estúpido, não estava bloqueando a todos! Eu só estava confiando demais em saída do console ..

Answer 1

É provavelmente o bloqueio na chamada para se conectar, depois do printf.

stdout é linha tamponada por padrão, e desde que você não tem um \ n no final da seqüência de printf, você não vai ver a sua saída. Quando você matar o programa, o buffer está sendo liberado, razão pela qual você vê a mensagem depois.