Há muitos conceitos novos para entender no asyncio, mas a lógica básica do blogdom.py: procura domínios para um blog sobre Python é fácil de compreender se você usar o truque sugerido pelo próprio Guido van Rossum: finja que as palavras-chave async e await não estão ali. Fazendo isso, você vai perceber que a lógica de uma corrotina pode ser lida como uma função sequencial.

Por exemplo, imagine que o corpo desta corrotina…​

…​funciona como a função abaixo, exceto que, magicamente, ela nunca bloqueia a execução do laço de eventos:

Usar a sintaxe await loop.getaddrinfo(…​) evita o bloqueio, porque await suspende somente o objeto corrotina atual. Por exemplo, durante a execução da corrotina probe('if.dev'), um novo objeto corrotina é criado por getaddrinfo('if.dev', None). Aplicar await sobre ele inicia a consulta de baixo nível addrinfo e devolve o controle para o laço de eventos, não para a corrotina probe(‘if.dev’), que está suspensa. Enquanto isso, o laço de eventos pode ativar outros objetos corrotina pendentes, tal como probe('or.dev').

Quando o laço de eventos recebe a resposta da consulta getaddrinfo('if.dev', None), aquele objeto corrotina específico prossegue sua execução, e devolve o controle para probe('if.dev')—que estava suspenso no await—e pode agora tratar alguma possível exceção e devolver a tupla com o resultado.

Até aqui, vimos asyncio.as_completed e await sendo aplicados apenas a corrotinas. Mas eles podem lidar com qualquer objeto "esperável". Esse conceito será explicado a seguir.

A diferença fundamental entre os exemplos de corrotinas clássicas vistas na [classic_coroutines_sec] e flags_asyncio.py é que não há chamadas a .send() ou expressões yield visíveis nesse último. O seu código fica entre a biblioteca asyncio e as bibliotecas assíncronas que você estiver usando, como por exemplo a HTTPX. Isso está ilustrado na Em um programa assíncrono, uma função do usuário inicia o laço de eventos, agendando uma corrotina inicial com asyncio.run. Cada corrotina do usuário aciona a seguinte com uma expressão await, formando um canal que permite a comunicação direta entre uma biblioteca como a HTTPX e o laço de eventos do framework assíncrono..

Debaixo dos panos, o laço de eventos do asyncio faz as chamadas a .send que acionam as nossas corrotinas, e nossas corrotinas acionam outras corrotinas com await, inclusive corrotinas da biblioteca. Como já mencionado, a maior parte da implementação de await vem de yield from, que internamente invoca .send para acionar as corrotinas.

O canal await termina em um esperável de baixo nível da biblioteca HTTPX, que devolve um gerador que o laço de eventos pode acionar em resposta a eventos tais como E/S de rede ou timers. Os esperáveis e geradores no final desses canais await estão implementados nas profundezas das bibliotecas, não são parte de suas APIs e podem ser extensões Python/C.

Usando funções como asyncio.gather e asyncio.create_task, podemos ter múltiplos canais de await ao mesmo tempo, permitindo acionar operações de E/S concorrentes em um único laço de eventos, em uma única thread.

No flags_asyncio.py: imports e funções de download, note que eu reutilizei a função get_flag de flags.py ([flags_module_ex] do [ch_executors]). Tive que reescrevê-la como uma corrotina para usar a API assíncrona do HTTPX. Para obter o melhor desempenho do asyncio, precisamos substituir todas as funções que fazem E/S por uma versão assíncrona, que seja acionada com await ou asyncio.create_task. Assim o controle é devolvido ao laço de eventos, enquanto não chega a resposta da operação de envio ou recebimento de dados. Se for inviável reescrever a função bloqueante como uma corrotina, devemos executá-la em outra thread ou processo, como veremos na Delegando tarefas a executores.

Por isso escolhi a epígrafe desse capítulo, que inclui o conselho: "Ou você reescreve todo o código, de forma que nada nele bloqueie ou está só perdendo tempo."

Pela mesma razão, também não pude reutilizar a função download_one de flags_threadpool.py ([flags_threadpool_ex] do [ch_executors]). O código no flags_asyncio.py: imports e funções de download aciona get_flag com await, então download_one precisa também ser uma corrotina. Para cada requisição, supervisor cria um objeto corrotina download_one, e eles são todos acionados pela corrotina asyncio.gather.

Vamos agora estudar a instrução async with, que apareceu em supervisor (flags_asyncio.py: funções de inicialização) e get_flag (flags_asyncio.py: imports e funções de download).

No flags_asyncio.py: imports e funções de download, passamos várias corrotinas para asyncio.gather, que devolve uma lista com os resultados das corrotinas na ordem em que foram submetidas. Isto significa que asyncio.gather só pode retornar quando todos os esperáveis terminarem. Entretanto, para atualizar a barra de progresso, precisamos receber cada resultado assim que ele está pronto.

Felizmente existe uma equivalente assíncrona da função geradora as_completed que usamos no exemplo de banco de threads com a barra de progresso, ([flags2_threadpool_full] do [ch_executors]).

O flags2_asyncio.py: parte superior (inicial) do script; o resto do código está no [flags2_asyncio_rest] mostra o início do script flags2_asyncio.py, onde as corrotinas get_flag e download_one são definidas. O flags2_asyncio.py: continuação de [flags2_asyncio_top] lista o restante do código-fonte, com supervisor e download_many. O script é maior que flags_asyncio.py por causa do tratamento de erros.

1. get_flag é muito similar à versão sequencial no [flags2_basic_http_ex]. Primeira diferença: ela requer o parâmetro client.

2. Segunda e terceira diferenças: .get é um método de AsyncClient, e é uma corrotina, então precisamos acioná-la com await.

3. Usa o semaphore como um gerenciador de contexto assíncrono, assim o programa todo não é bloqueado; apenas essa corrotina é suspensa quando o contador do semáforo é zero. Veremos mais sobre isso na caixa Semáforos no Python, Limitando as requisições com um semáforo.

4. A lógica de tratamento de erro é idêntica à de download_one, do [flags2_basic_http_ex] do [ch_executors].

5. Salvar a imagem é uma operação de E/S. Para não bloquear o laço de eventos, roda save_flag em uma thread.

No asyncio, toda a comunicação de rede é feita com corrotinas, mas não E/S de arquivos. Entretanto, E/S de arquivos também é "bloqueante"—pois ler/escrever arquivos é «milhares de vezes mais demorado» que ler/escrever na RAM. Se você estiver usando «armazenamento conectado à rede», acessar "o disco" significa fazer E/S na rede local.

Desde o Python 3.9, a corrotina asyncio.to_thread facilitou delegar operações de arquivo para um banco de threads fornecido pelo asyncio. Se você precisa suportar Python 3.7 ou 3.8, a Delegando tarefas a executores mostra como fazer isso, adicionando algumas linhas ao seu programa. Mas antes, vamos terminar nosso estudo do código do cliente HTTP.

Clientes de rede como os que estamos estudando devem ser throttled (limitados no desempenho) para não martelarem o servidor com um número excessivo de requisições concorrentes.

Um semáforo é uma estrutura primitiva de sincronização, mais flexível que uma trava. O mesmo semáforo é usado por várias corrotinas, com um número máximo configurável. Assim podemos limitar o número de corrotinas concorrentes ativas usando o semáforo. A caixa Semáforos no Python tem mais informações.

No flags2_threadpool.py ([flags2_threadpool_full] do [ch_executors]), a limitação de desempenho (throttling) foi feita na função download_many instanciando o ThreadPoolExecutor passando um número máximo de threads no argumento max_workers. Em flags2_asyncio.py, um asyncio.Semaphore é criado pela função supervisor (mostrada no flags2_asyncio.py: continuação de [flags2_asyncio_top]) e passado como o argumento semaphore para download_one no flags2_asyncio.py: parte superior (inicial) do script; o resto do código está no [flags2_asyncio_rest].

Agora vamos olhar o resto do script no flags2_asyncio.py: continuação de [flags2_asyncio_top].

1. supervisor recebe os mesmos argumentos que a função download_many, mas não pode ser invocada diretamente de main, pois é uma corrotina e não uma função comum como download_many.

2. Cria um asyncio.Semaphore que não vai permitir mais que concur_req corrotinas ativas entre aquelas usando este semáforo. O valor de concur_req é calculado pela função main de flags2_common.py, baseado nas opções de linha de comando e nas constantes definidas em cada exemplo.

3. Cria uma lista de objetos corrotina, um para cada chamada à corrotina download_one.

4. Obtém um iterador que vai devolver objetos corrotina quando eles terminarem sua execução. Não coloquei essa chamada a as_completed diretamente no laço for abaixo porque posso precisar envolvê-la com o iterador tqdm para a barra de progresso, dependendo da opção de verbosidade na linha de comando.

5. Envolve o iterador as_completed com a função geradora tqdm, para mostrar o progresso.

6. Declara e inicializa error com None; esta variável será usada para salvar uma exceção além do bloco try/except, se alguma for levantada.

7. Itera pelos objetos corrotina que terminaram a execução; este laço é similar ao de download_many no [flags2_threadpool_full] do [ch_executors].

8. Aciona a corrotina com await para obter seu resultado. Isto não bloqueia porque as_completed só produz corrotinas que já terminaram.

9. Esta atribuição é necessária porque o escopo da variável exc é limitado a esta cláusula except, mas preciso preservar o valor para uso posterior.

10. Mesmo que acima.

11. Se houve um erro, muda o status.

12. Em modo verboso, extrai a URL da exceção que foi levantada…​

13. …​e extrai o nome do arquivo para mostrar o código do país em seguida.

14. download_many instancia o objeto corrotina supervisor e o passa para o laço de eventos com asyncio.run, coletando o contador que supervisor devolve quando o laço de eventos termina.

No flags2_asyncio.py: continuação de [flags2_asyncio_top], não pudemos usar o mapeamento de futures para os códigos de país que vimos em [flags2_threadpool_full] do [ch_executors], porque os esperáveis devolvidos por asyncio.as_completed não são necessariamente os mesmos esperáveis que passamos na invocação de as_completed. Internamente, a lógica do asyncio pode embrulhar os esperáveis que fornecemos por outros esperáveis que afinal produzirão os mesmos resultados.^[8]

Isto encerra nossa discussão da funcionalidade de um cliente Web com tratamento de erros e barra de progresso, implementado com asyncio.

O próximo exemplo demonstra um modelo simples de execução de uma tarefa assíncrona após outra usando corrotinas.

Pessoas com experiência em JavaScript sabem que rodar uma função assíncrona após outra acabou gerando o padrão de funções aninhadas conhecido como pyramid of doom (pirâmide da perdição). A palavra-chave await desfaz a maldição. Por isso await agora é parte de Python e de JavaScript. Vamos a um exemplo.

Suponha que você queira salvar cada bandeira com o nome do país e o código, em vez de apenas o código. Agora você precisa fazer duas requisições HTTP por bandeira: uma para pegar a imagem da bandeira propriamente dita, a outra para pegar o arquivo metadata.json, no mesmo diretório da imagem—é nesse arquivo que o nome do país está registrado.

Coordenar múltiplas requisições na mesma tarefa é fácil no script com threads: basta fazer uma requisição depois a outra, bloqueando a thread duas vezes, e preservando os dados (código e nome do país) em variáveis locais, prontas para serem usadas na hora de salvar o arquivo. Se você precisasse fazer o mesmo em um script assíncrono com callbacks, precisaria de funções aninhadas, de forma que o código e o nome do país estivessem disponíveis em clausuras até o momento de salvar o arquivo, pois cada callback roda em um escopo local diferente. A palavra-chave await evita este aninhamento, permitindo que você acione as requisições assíncronas uma após a outra, compartilhando o escopo local da corrotina que aciona as ações.

A terceira variante do script asyncio de download de bandeiras traz algumas mudanças:

get_country

Esta nova corrotina baixa o arquivo metadata.json daquele código de país, e extrai dele o nome do país.

download_one

Esta corrotina agora usa await para delegar para get_flag e para a nova corrotina get_country, usando o resultado dessa última para compor o nome do arquivo a ser salvo.

Vamos começar com o código de get_country (flags3_asyncio.py: corrotina get_country). Note que é muito parecido com o get_flag do flags2_asyncio.py: parte superior (inicial) do script; o resto do código está no [flags2_asyncio_rest].

1. Esta corrotina devolve uma string com o nome do país—se tudo correr bem.

2. metadata vai receber um dict Python construído a partir do conteúdo JSON da resposta.

3. Devolve o nome do país.

Agora vamos ver o download_one modificado do flags3_asyncio.py: corrotina download_one, que tem apenas algumas linhas diferentes da corrotina de mesmo nome do flags2_asyncio.py: parte superior (inicial) do script; o resto do código está no [flags2_asyncio_rest].

1. Retém o semaphore para acionar get_flag…​

2. …​e novamente para acionar get_country.

3. Usa o nome do país para criar um nome de arquivo. Como usuário da linha de comando, não gosto de espaços em nomes de arquivo.

Muito melhor que callbacks aninhados!

Coloquei as chamadas a get_flag e get_country em blocos with separados, controlados pelo semaphore porque é uma boa prática reter semáforos e travas pelo menor tempo possível.

Eu poderia ter agendado as funções get_flag e get_country, em paralelo, usando asyncio.gather, mas se get_flag levantar uma exceção não haverá imagem para salvar, então é inútil rodar get_country. Mas há casos em que faz sentido usar asyncio.gather para acessar várias APIs simultaneamente, em vez de esperar por uma resposta antes de fazer a próxima requisição

Em flags3_asyncio.py, a sintaxe await aparece seis vezes, e async with três vezes. Espero que você esteja pegando o jeito da programação assíncrona em Python.

Um desafio é saber quando você precisa usar await e quando você não pode usá-la. A resposta, em princípio, é fácil: use await para acionar corrotinas e outros esperáveis, como instâncias de asyncio.Task. Mas algumas APIs são complexas, misturam corrotinas e funções comuns de forma aparentemente arbitrária, como a classe StreamWriter que usaremos no tcp_mojifinder.py: continuação de [ex_tcp_mojifinder_main].

O flags3_asyncio.py: corrotina download_one encerra o grupo de exemplos flags. Vamos agora discutir o uso de executores de threads ou processos na programação assíncrona.

Escrevi o próximo exemplo—web_mojifinder.py—usando o FastAPI: um dos frameworks ASGI para desenvolvimento Web em Python, mencionado na [wsgi_app_server_sec]. A Janela de navegador mostrando os resultados da busca por "mountain" no serviço web_mojifinder.py. é uma captura de tela da interface de usuário. É uma aplicação simples, de uma página só (SPA, Single Page Application): após o download inicial do HTML, a interface é atualizada via JavaScript no cliente, em comunicação com o servidor.

O FastAPI foi projetado para implementar o lado servidor de SPAs e aplicativos de celular, que consistem principalmente de pontos de acesso de APIs Web, devolvendo respostas JSON em vez de HTML renderizado no servidor. O FastAPI se vale de decoradores, dicas de tipo e introspecção de código para eliminar muito código repetitivo das APIs Web, e também gera uma documentação no padrão OpenAPI do Swagger. A Documentação OpenAPI do ponto de acesso /search, gerada automaticamente. mostra a página /docs do web_mojifinder.py, gerada automaticamente.

O web_mojifinder.py: código-fonte completo é o código de web_mojifinder.py, mas é só código do lado servidor. Quando você acessa a URL raiz /, o servidor envia o arquivo form.html, que contém 81 linhas de código, incluindo 54 linhas de JavaScript para comunicação com o servidor e preenchimento da tabela com os resultados. Se tiver interesse em ler JavaScript puro sem uso de frameworks, confira o 21-async/mojifinder/static/form.html no «repositório de código» do Python Fluente.

Para rodar o web_mojifinder.py, você precisa instalar dois pacotes e suas dependências: FastAPI e uvicorn.^[10]

Este é o comando para executar o web_mojifinder.py: código-fonte completo com uvicorn em modo de desenvolvimento:

os parâmetros são:

web_mojifinder:app

O nome do pacote, dois pontos, e o nome da aplicação ASGI definida nele—app é o nome usado por convenção.

--reload

Faz o uvicorn monitorar mudanças no código-fonte da aplicação, e recarregá-la automaticamente. Útil apenas durante o desenvolvimento.

Vamos agora olhar o código-fonte do web_mojifinder.py.

1. Não relacionado ao tema desse capítulo, mas digno de nota: o uso elegante do operador / sobrecarregado por pathlib.^[11]

2. Esta linha define a app ASGI. Ela poderia ser apenas app = FastAPI(). Os parâmetros são metadados para a documentação da API, gerada automaticamente.

3. Um schema pydantic para uma resposta JSON, com campos char e name.^[12]

4. Cria o index e carrega o formulário HTML estático, anexando ambos ao app.state para uso posterior.

5. Roda init quando esse módulo é carregado pelo servidor ASGI.

6. Rota para o ponto de acesso /search; response_model usa aquele modelo CharName do pydantic para descrever o formato da resposta.

7. O FastAPI assume que qualquer parâmetro que apareça na assinatura da função ou da corrotina e que não esteja no caminho da rota será passado na string de consulta HTTP, isto é, /search?q=cat. Como q não tem default, a FastAPI devolverá um status 422 (Unprocessable Entity, Entidade Não-Processável) se q não estiver presente na string da consulta.

8. Devolver um iterável de dicts compatível com o schema response_model permite ao FastAPI criar uma resposta JSON de acordo com o response_model no decorador @app.get,

9. Funções regulares (isto é, não-assíncronas) também podem ser usadas para produzir respostas.

10. Este módulo não tem uma função principal. É carregado e acionado pelo servidor ASGI—neste exemplo, o uvicorn.

O web_mojifinder.py: código-fonte completo não faz chamada direta ao asyncio. O FastAPI é construído sobre o toolkit ASGI Starlette, que por sua vez usa o asyncio.

Note também que o corpo de search não usa await, async with, ou async for, então poderia ser uma função comum. Defini search como uma corrotina apenas para mostrar que o FastAPI sabe como lidar com elas. Em uma aplicação real, a maioria dos pontos de acesso serão consultas a bancos de dados ou acessos a outros servidores remotos, então é uma vantagem importante do FastAPI—e dos frameworks ASGI em geral— suportarem corrotinas que podem se valer de bibliotecas assíncronas para E/S de rede.

Os entusiastas da tipagem estática podem ter notado que não coloquei dicas de tipo para os resultados devolvidos por search e form. Em vez disto, o FastAPI aceita o argumento nomeado response_model= nos decoradores de rota. A página Response Model - Return Type da documentação do FastAPI explica:

O modelo de resposta é declarado neste parâmetro em vez de como uma anotação de tipo de resultado devolvido por uma função, porque a função de rota pode não devolver aquele modelo de resposta mas sim um dict, um objeto do banco de dados ou algum outro modelo, e então usar o response_model para realizar a validação de campos e a serialização.

Por exemplo, em search, devolvi um gerador de itens dict e não uma lista de objetos CharName, mas isso basta para o FastAPI e o pydantic validarem meus dados e construírem a resposta JSON apropriada, compatível com response_model=list[CharName].

Agora vamos analisar outro servidor que usa sockets TCP e a biblioteca padrão do Python para responder consultas via Telnet no terminal.

O programa tcp_mojifinder.py usa TCP puro para se comunicar com um cliente como o Telnet ou o Netcat, então pude escrevê-lo usando asyncio sem dependências externas, e sem reinventar o HTTP. A Sessão de telnet com o servidor tcp_mojifinder.py: consultando "fire." mostra a interface de usuário em modo texto.

Este programa é duas vezes mais longo que o web_mojifinder.py (descontando o HTML e o JavaScript daquele exemplo). Por isso dividi a apresentação em três partes: tcp_mojifinder.py: um servidor TCP simples; continua no [tcp_mojifinder_top], tcp_mojifinder.py: continuação de [ex_tcp_mojifinder_main], e tcp_mojifinder.py: corrotina search. O topo do arquivo tcp_mojifinder.py, com as instruções import, está no tcp_mojifinder.py: continuação de [ex_tcp_mojifinder_main]. Mas vou começar descrevendo a corrotina supervisor e a função main que controlam o programa.

1. Este await devolve uma instância de asyncio.Server, um servidor TCP baseado em sockets. Por padrão, start_server cria e inicia o servidor, então ele está pronto para receber conexões.

2. O primeiro argumento para start_server é client_connected_cb, uma função de callback para ser executada quando a conexão com um novo cliente se inicia. Ela pode ser uma função ou uma corrotina, mas precisa aceitar exatamente dois argumentos: um asyncio.StreamReader e um asyncio.StreamWriter. Porém, minha corrotina finder também precisa receber um index, então usei functools.partial para vincular aquele parâmetro e obter um invocável que recebe o leitor (StreamReader) e o escritor (StreamWriter). Adaptar funções do usuário a APIs de callback é o caso de uso mais comum de functools.partial.

3. host e port são o segundo e o terceiro argumentos de start_server. Veja a assinatura completa na «documentação do asyncio».

4. Este cast é necessário porque o typeshed tem uma dica de tipo desatualizada para a propriedade sockets da classe Server em maio de 2021. Veja «Issue #5535 no typeshed».^[13]

5. Exibe o endereço e a porta do primeiro socket do servidor.

6. Apesar de start_server já ter iniciado o servidor como uma tarefa concorrente, preciso usar o await no método serve_forever, para que meu supervisor seja suspenso aqui. Sem essa linha, o supervisor retornaria imediatamente, encerrando o laço iniciado com asyncio.run(supervisor(…)), e fechando o programa. A documentação de Server.serve_forever diz: "Este método pode ser chamado se o servidor já estiver aceitando conexões."

7. Constrói o índice invertido.^[14]

8. Inicia o laço de eventos rodando supervisor.

9. Captura KeyboardInterrupt para evitar um traceback ruidoso quando encerramos o servidor teclando CTRL-C no terminal onde ele está rodando.

Pode ser mais fácil entender como o controle flui em tcp_mojifinder.py estudando a saída que ele gera no console do servidor, listada no tcp_mojifinder.py: isso é o lado servidor da sessão mostrada na [tcp_mojifinder_demo].

1. Saída de main. Antes da próxima linha aparecer, notei um intervalo de 0,6s na minha máquina, enquanto o índice era construído.

2. Saída de supervisor.

3. Primeira volta do laço while na função finder do tcp_mojifinder.py: continuação de [ex_tcp_mojifinder_main]. A pilha TCP/IP atribuiu a porta 58192 a meu cliente Telnet. Se você conectar diversos clientes ao servidor, verá suas diferentes portas aparecerem na saída.

4. Segunda iteração do laço while em finder.

5. Teclei CTRL-C no terminal do cliente; o laço while em finder termina.

6. A corrotina finder exibe esta mensagem e encerra. Enquanto isso o servidor continua rodando, pronto para receber outros clientes.

7. Teclei CTRL-C no terminal do servidor; server.serve_forever é cancelado, encerrando supervisor e o laço de eventos.

8. Saída de main.

Após main construir o índice e iniciar o laço de eventos, a corrotina supervisor rapidamente exibe a mensagem Serving on…​, e fica suspensa na última linha:

Neste ponto o controle flui para o laço de eventos do asyncio e lá permanece, voltando ocasionalmente para a corrotina finder, que devolve o controle de volta para o laço de eventos sempre que precisa esperar a rede para enviar ou receber dados.

Enquanto o laço de eventos estiver ativo, uma nova instância da corrotina finder será iniciada para cada cliente que se conecte ao servidor. Desta forma, milhares de clientes podem ser atendidos concorrentemente por este servidor simples. Isto segue até que ocorra um KeyboardInterrupt no servidor ou que seu processo seja encerrado pelo SO.

Agora vamos ver o início de tcp_mojifinder.py, com a corrotina finder.

1. format_results é útil para mostrar os resultados de InvertedIndex.search em uma interface de usuário baseada em texto, como a linha de comando ou uma sessão Telnet.

2. Para passar finder para asyncio.start_server, a envolvi com functools.partial, porque o servidor espera uma corrotina ou função que receba apenas os argumentos reader e writer.

3. Obtém o endereço do cliente remoto ao qual o socket está conectado.

4. Este laço controla um diálogo que persiste até um caractere de controle ser recebido do cliente.

5. O método StreamWriter.write não é uma corrotina, é uma função comum. Esta linha envia o prompt ?>.

6. StreamWriter.drain esvazia o buffer de writer; ela é uma corrotina, então precisa ser acionada com await.

7. StreamWriter.readline é uma corrotina que devolve bytes.

8. Se nenhum byte foi recebido, o cliente fechou a conexão, então sai do loop.

9. Decodifica os bytes para str, usando a codificação UTF-8 como default.

10. Pode ocorrer um UnicodeDecodeError quando o usuário digita CTRL-C e o cliente Telnet envia caracteres de controle; se isso acontecer, substitui a consulta pelo caractere null, para simplificar.

11. Registra a consulta no console do servidor.

12. Sai do laço se um caractere de controle ou null foi recebido.

13. search realiza a busca; o código será apresentado a seguir.

14. Registra a resposta no console do servidor.

15. Fecha o StreamWriter.

16. Espera até StreamWriter fechar. Isso é recomendado na documentação do método .close().

17. Registra o final dessa sessão do cliente no console do servidor.

O último trecho deste código é a corrotina search, tcp_mojifinder.py: corrotina search.

1. search precisa ser uma corrotina, pois escreve em um StreamWriter e precisa acionar o método corrotina .drain().

2. Consulta o índice invertido.

3. Esta expressão geradora produzirá strings de bytes codificadas em UTF-8 com o ponto de código Unicode, o caractere, seu nome e uma sequência CRLF (Return+Line Feed), isto é, b’U+0039\t9\tDIGIT NINE\r\n'.

4. Envia lines. Surpreendentemente, writer.writelines não é uma corrotina.

5. Mas writer.drain() é uma corrotina. Não esqueça do await!

6. Constrói e envia uma linha de status.

Observe que toda a E/S de rede em tcp_mojifinder.py é feita em bytes; precisamos decodificar os bytes recebidos da rede, e codificar strings antes de enviá-las. No Python 3, a codificação default é UTF-8, e foi o que usei implicitamente em todas as chamadas a encode e decode nesse exemplo.

O código de tcp_mojifinder.py se vale da «API de streams» de alto nível do asyncio, que fornece um servidor pronto para usar, então só precisamos codar uma função de processamento, que pode ser um callback simples ou uma corrotina. Há também uma «API de Transportes e Protocolos» de baixo nível, inspirada nas abstrações de transporte e protocolo do framework Twisted. Veja a documentação do asyncio para mais informações, incluindo os «servidores echo e clientes TCP e UDP» implementados com a API de baixo nível.

Nosso próximo tópico é a instrução async for e os objetos que a fazem funcionar.

Você pode implementar um iterador assíncrono escrevendo uma classe com __anext__ e __aiter__, mas há um jeito mais fácil: escreva uma função declarada com async def que use yield em seu corpo. Isto é semelhante à forma como funções geradoras simplificam o implementar o padrão do Iterador clássico.

Vamos estudar um exemplo simples usando async for e implementando um gerador assíncrono. No blogdom.py: procura domínios para um blog sobre Python vimos blogdom.py, um script que sondava nomes de domínio. Suponha agora que encontramos outros usos para a corrotina probe definida ali, e decidimos colocá-la em um novo módulo (domainlib.py) com um novo gerador assíncrono multi_probe, que recebe uma lista de nomes de domínio e produz resultados conforme eles são sondados.

Vamos ver a implementação de domainlib.py logo, mas primeiro examinaremos como ele é usado com o novo console assíncrono de Python.

A PEP 530—Asynchronous Comprehensions introduziu o uso de async for e await na sintaxe de compreensões e expressões geradoras, a partir do Python 3.6.

A única sintaxe definida na PEP 530 que pode aparecer fora do corpo de uma async def é uma expressão geradora assíncrona.

Um TaskGroup do Curio é um gerenciador de contexto assíncrono que substitui várias APIs e padrões de codificação repetitivos do asyncio. Acabamos de ver como iterar sobre um TaskGroup torna a função asyncio.as_completed(…) desnecessária.

Outro exemplo: em vez da função especial gather, este trecho da documentação de "Task Groups" coleta os resultados de todas as tarefas no grupo:

Objetos TaskGroup suportam «concorrência estruturada»: uma disciplina de programação concorrente que organiza todas a atividades de um grupo de tarefas assíncronas em um bloco de código com apenas um ponto de entrada e uma saída. Isto é análogo à programação estruturada, que introduziu instruções de bloco para limitar os pontos de entrada e saída de condicionais, laços e sub-rotinas, e eliminou a instrução GOTO que permitia desviar a execução direto para qualquer outra linha do código. Quando usado como um gerenciador de contexto assíncrono, um TaskGroup garante que na saída do bloco, todas as tarefas criadas dentro dele estão finalizadas ou canceladas e qualquer exceção foi levantada.

Outra inovação importante do Curio é um suporte melhor para programar com corrotinas e threads na mesma base de código—uma necessidade de qualquer programa assíncrono não-trivial. Iniciar uma thread com await spawn_thread(func, …) devolve um objeto AsyncThread com uma interface de Task. As threads podem chamar corrotinas, graças à função especial AWAIT(coro)—escrita inteiramente com maiúsculas porque await agora é uma palavra-chave.

O Curio também oferece uma UniversalQueue que pode ser usada para coordenar o trabalho entre threads, corrotinas Curio e corrotinas asyncio. Sim, o Curio pode ser executado em uma thread ao lado do asyncio em outra thread, no mesmo processo, comunicando-se através de UniversalQueue e de UniversalEvent. A API destas classes "universais" é a mesma dentro e fora de corrotinas, mas em uma corrotina é preciso acionar os métodos com await.

Em outubro de 2021, quando estou escrevendo esse capítulo, a HTTPX é a primeira biblioteca HTTP cliente compatível com o Curio, mas não sei de nenhuma biblioteca assíncrona de banco de dados que o suporte nesse momento. No repositório do Curio há um conjunto impressionante de «exemplos de programação para rede», incluindo um que utiliza WebSocket, e outro implementando o algoritmo concorrente RFC 8305—Happy Eyeballs, para conexão com pontos de acesso IPv6 revertendo rapidamente para IPv4 quando necessário.

O design do Curio foi muito influente. o framework Trio, iniciado por Nathaniel J. Smith, foi muito inspirado nele. O Curio pode também ter estimulado os contribuidores de Python a melhorar a usabilidade da API do asyncio. Por exemplo, em suas primeiras versões, os usuários do asyncio muitas vezes eram obrigados a obter e ficar passando um objeto loop, porque algumas funções essenciais eram métodos de loop, ou precisavam do laço de eventos como um argumento. Em versões mais recentes de Python, acesso direto ao laço não é mais tão necessário e, várias funções que aceitavam um loop opcional estão agora descontinuando aquele argumento.

Anotações de tipo para tipos assíncronos é o nosso próximo tópico.

Ryan Dahl, o inventor do Node.js, introduz a filosofia do projeto dizendo "Estamos fazendo E/S de forma totalmente errada."^[18] Ele define uma "função bloqueante" como uma função que faz E/S de arquivo ou rede, e argumenta que elas não podem ser tratadas da mesma forma que tratamos funções não-bloqueantes. Para explicar a razão disso, ele apresenta os números na segunda coluna da Latência em computadores modernos para ler dados em diferentes dispositivos. A terceira coluna mostra os tempos proporcionais em uma escala fácil de entender para nós, humanos vagarosos..

Para entender a Latência em computadores modernos para ler dados em diferentes dispositivos. A terceira coluna mostra os tempos proporcionais em uma escala fácil de entender para nós, humanos vagarosos., tenha em mente que as CPUs modernas, com seus clocks em frequências na casa dos GHz, rodam bilhões de ciclos por segundo. Suponha que uma CPU rode exatamente 1 bilhão de ciclos por segundo. Tal CPU pode realizar mais de 333 milhões de leituras do cache L1 em 1 segundo, ou 4 (quatro!) leituras da rede no mesmo segundo. A terceira coluna da Latência em computadores modernos para ler dados em diferentes dispositivos. A terceira coluna mostra os tempos proporcionais em uma escala fácil de entender para nós, humanos vagarosos. coloca os números em perspectiva, multiplicando a segunda coluna por um fator constante. Então, em um universo alternativo, se uma leitura da RAM demorasse 250 segundos, uma leitura da rede demoraria 7,6 anos! A diferença quantitativa é tão grande que se torna uma diferença qualitativa importante: esperar 250 segundos é muito diferente de esperar 7,6 anos!

A Latência em computadores modernos para ler dados em diferentes dispositivos. A terceira coluna mostra os tempos proporcionais em uma escala fácil de entender para nós, humanos vagarosos. explica por que uma abordagem disciplinada da programação assíncrona pode levar a servidores de alto desempenho. O desafio é alcançar esta disciplina. O primeiro passo é reconhecer que um sistema limitado apenas por E/S é uma fantasia.

Um meme exaustivamente repetido é que programação assíncrona é boa para I/O bound systems (sistemas limitados por E/S), ou seja, sistemas onde o gargalo é a entrada e saída de dados, e não o processamento de dados na CPU. Aprendi da forma mais difícil que não existem "sistemas limitados por E/S." Você pode ter funções limitadas por E/S. Talvez a maioria das funções no seu sistema sejam limitadas por E/S; isto é, elas passam mais tempo esperando por E/S do que realizando operações na CPU e na memória. Enquanto esperam, cedem o controle para o laço de eventos, que pode então acionar outras tarefas pendentes. Mas, inevitavelmente, qualquer sistema não-trivial terá partes limitadas pela CPU. Até mesmo sistemas triviais revelam isso, sob stress. Na caixa Ponto de vista ao final deste capítulo escrevi sobre dois programas assíncronos sofrendo com funções limitadas pela CPU que atrasavam o laço de eventos, com severos impactos no desempenho do sistema como um todo.

Dado que qualquer sistema não-trivial terá funções limitadas pela CPU, lidar com elas é a chave do sucesso na programação assíncrona.

Se você está usando Python em larga escala, precisa ter testes automatizados especificamente para detectar regressões de desempenho assim que elas acontecem. Isso é de importância crítica com código assíncrono, mas é relevante também para código Python baseado em threads—por causa da GIL. Se você esperar até a lentidão começar a incomodar a equipe de desenvolvimento, será tarde demais. A solução poderá exigir mudanças drásticas.

Aqui estão algumas opções para quando você identifica gargalos de uso da CPU:

• Delegar a tarefa para um banco de processos Python.

• Delegar a tarefa para uma fila de tarefas externa.

• Reescrever o código relevante em Cython, C, Rust ou alguma outra linguagem que compile para código de máquina e faça interface com a API Python/C, de preferência liberando a GIL.

• Decidir que pode tolerar a perda de desempenho e deixar como está—mas registre essa decisão, para ficar mais fácil revertê-la no futuro.

A fila de tarefas externa deveria ser escolhida e integrada o mais rápido possível, no início do projeto, para que ninguém na equipe hesite em usá-la quando necessário.

A opção de deixar como está entra na conta de «dívida tecnológica».

Programação concorrente é um tópico fascinante, e eu gostaria de escrever mais. Mas não é o foco principal deste livro, e este já é um dos capítulos mais longos, então vamos encerrar por aqui.