OWaitNamedPipe função @ permite que um aplicativo cliente de pipe aguarde de forma síncrona por uma conexão disponível em um servidor de pipe nomeado. Você então chamaCreateFile para abrir o tubo como um cliente. Pseudo-código

// loop works around race condition with WaitNamedPipe and CreateFile
HANDLE hPipe;
while (true) {
    if (WaitNamedPipe says connection is ready) {
        hPipe = CreateFile(...);
        if (hPipe ok or last error is NOT pipe busy) {
            break; // hPipe is valid or last error is set
        }
    } else {
        break; // WaitNamedPipe failed
    }
}

O problema é que todas estas são chamadas síncronas e bloqueadoras. Qual é uma boa maneira de fazer isso de forma assíncrona? Não consigo encontrar uma API que use E / S sobrepostas para fazer isso, por exemplo. Por exemplo, para pipe servers aConnectNamedPipe função @ fornece umlpOverlapped parâmetros que permitem que um servidor aguarde assincronamente por um cliente. O servidor de pipe pode então chamar WaitForMultipleObjects e aguarde a conclusão da operação de E / S ou qualquer outro evento a ser sinalizado (por exemplo, um evento sinalizando o encadeamento para cancelar E / S pendentes e terminar

A única maneira de pensar é ligar paraWaitNamedPipe em um loop com um tempo limite curto e finito e verifique outros sinais se o tempo expirar. Como alternativa, em uma chamada de loopCreateFile, verifique outros sinais e ligue paraSleep com um pequeno atraso (ouWaitNamedPipe). Por exemplo

HANDLE hPipe;
while (true) {
    hPipe = CreateFile(...);
    if (hPipe not valid and pipe is busy) {
        // sleep 100 milliseconds; alternatively, call WaitNamedPipe with timeout
        Sleep(100);
        // TODO: check other signals here to see if we should abort I/O
    } else
        break;
}

Mas este método fede ao céu na minha opinião. Se um canal não estiver disponível por algum tempo, o encadeamento continuará funcionando - sugando a CPU, consumindo energia, exigindo que as páginas de memória permaneçam na RAM, etc. Na minha opinião, um encadeamento que depende deSleep ou tempos de espera curtos não apresentam um bom desempenho e são um sinal de programação multithread desleixad

Mas qual é a alternativa nesse caso?