Fala!

Hoje eu quero que você entenda o event loop, vou te explicar o que você precisa saber para mandar bem nas entrevistas e entender o coração do Node.

Como o nome diz o event loop é um laço de eventos responsável por gerenciar quando e como seu código é executado — especialmente quando tem tarefas assíncronas.

Tá, mas o que é uma tarefa assíncrona?

• Ler um arquivo do disco
• Esperar uma resposta HTTP
• Esperar um setTimeout
• Consultar banco de dados

Importante, isso quer dizer que ele pode executar outros processos enquanto consulta dados no banco ou espera uma resposta HTTP.

O Node, por exemplo, é single-threaded (roda em uma thread principal), mas ele usa o event loop para parecer que faz várias coisas ao mesmo tempo.

A ideia principal

Agora vou te mostrar a ideia principal do Node e é onde fica a escalabilidade dele e de outras linguagens como o Python e Java.

• O Node recebe um evento, como uma requisição HTTP — event queue

• O _callback_associado a esse evento é enviado para execução

  • Se for algo demorado do tipo acessar banco ele é delegada para as threads do libuv.

• Enquanto isso, o event loop continua livre para processar outros eventos.

• Quando a operação assíncrona termina, o resultado é colocado de volta na fila de callbacks, e o event loop chama o callback correspondente.

• O ciclo se repete indefinidamente — o loop nunca para, a menos que não haja mais nada para processar.

Node manda o evento assíncrono para uma thread secundária sem travar a fila. Quando a thread termina, o resultado do evento é enviado de volta para o loop principal e o callback é executado.

Fases do event loop

O Node executa todas essas fases, mas se não tiver processo nenhum ele pula ela, por exemplo, a fase 1 que é o timer, se não tiver um setTimeout ou setInterval no seu código ele pula essa fase.

Ele divide a execução de callbacks nessas fases e o loop vai passando por elas de forma cíclica enquanto houver tarefas para executar.

1. Timers

   (

   setTimeout

   e

   setInterval

   ) — só executa se estiver no código.

   1. Execulta callbacks de temporizadores cujo tempo já expirou.
   2. Callback de 0ms não é instantâneo: ele entra na fila de timers e só é executado quando o loop chegar nessa fase.

2. Pending callbacks

   1. Trata callbacks de operações assíncronas do sistema, como erros TCP ou algumas operações de I/O.

3. Idle, Prepare

   1. Fase interna do Node, não interagimos com ela diretamente

4. Poll

   (a mais importante)

   1. Fica esperando eventos de I/O (rede, arquivos, timers expirados, etc).
   2. Se houver callbacks prontos, ele os executa aqui
   3. Se não hover nada, ele espera ou vai para a fase de check (setImmediate) dependendo do estado do loop.
   4. A leitura é feita no poll.
   5. Quando termina o callback é chamado.

5. Check

   (

   setImmediate

   )

   1. Sempre executa após o poll, mesmo que esteja vazio
   2. Útil quando você quer rodar algo assim que o I/O atual terminar.

6. Close callbacks

   1. Chamado quando algo é fechado, como sockets.
   2. Sempre executa após o fechamento da conexão.

Algo importante de entender é isso…

O event loop do Node passa por todas as fases em ciclo contínuo, mas cada fase só faz algo se houver callbacks na fila correspondente.

Caso contrário, o Node simplesmente pula para a próxima fase.

Loop Infinito:

  1️⃣ Timers -> executa setTimeout/setInterval vencidos, senão pula
  2️⃣ I/O callbacks -> executa callbacks de operações I/O concluídas, senão pula
  3️⃣ Idle, prepare -> interno do Node, pouca coisa pra dev ver
  4️⃣ Poll -> verifica se há novas operações de I/O, senão aguarda
  5️⃣ Check -> executa setImmediate, senão pula
  6️⃣ Close callbacks -> executa callbacks de fechamento de sockets, senão pula

Então sim, todas as fases são "visitadas" em cada loop, mas só executam algo se tiver trabalho correspondente.

Bom pessoal é isso, espero que isso tenha te ajudado a entender.