1
00:00:01,150 --> 00:00:02,580
‫Instrutor: Bem-vindo de volta.

2
00:00:02,580 --> 00:00:05,000
‫Agora vamos aprender tudo sobre o loop de eventos, que

3
00:00:05,000 --> 00:00:08,150
‫é o coração do Nó. arquitetura js.

4
00:00:08,150 --> 00:00:10,580
‫E esta é provavelmente a palestra

5
00:00:10,580 --> 00:00:13,500
‫mais importante desta seção, então certifique-se de realmente

6
00:00:13,500 --> 00:00:16,510
‫entender tudo o que eu mostro durante este vídeo.

7
00:00:16,510 --> 00:00:17,813
‫Então vamos começar.

8
00:00:18,800 --> 00:00:21,880
‫Então, aqui está um diagrama semelhante à última

9
00:00:21,880 --> 00:00:25,170
‫aula para que saibamos exatamente do que estamos falando aqui.

10
00:00:25,170 --> 00:00:28,240
‫Portanto, ainda estamos em um processo Node na única thread em

11
00:00:28,240 --> 00:00:30,810
‫que o loop de eventos é executado, certo?

12
00:00:30,810 --> 00:00:32,530
‫Agora, a primeira coisa que você

13
00:00:32,530 --> 00:00:34,750
‫precisa saber é que o loop de evento é

14
00:00:34,750 --> 00:00:36,350
‫onde todo o código do

15
00:00:36,350 --> 00:00:39,550
‫aplicativo que está dentro das funções de retorno de chamada é executado.

16
00:00:39,550 --> 00:00:43,640
‫Portanto, basicamente, todo código que não seja um código de nível superior será

17
00:00:43,640 --> 00:00:45,250
‫executado no loop de eventos.

18
00:00:45,250 --> 00:00:48,450
‫Algumas partes podem ser descarregadas para o pool de threads

19
00:00:48,450 --> 00:00:50,140
‫como vimos na última aula,

20
00:00:50,140 --> 00:00:53,430
‫mas é o loop de eventos que cuida de tudo isso.

21
00:00:53,430 --> 00:00:56,370
‫Como eu disse antes, é realmente o coração

22
00:00:56,370 --> 00:00:58,360
‫da arquitetura do Node.

23
00:00:58,360 --> 00:01:01,660
‫Ok, agora, como mencionei muitas vezes na primeira parte

24
00:01:01,660 --> 00:01:04,300
‫do curso, Node. js é todo construído em

25
00:01:04,300 --> 00:01:05,860
‫torno de funções de retorno de chamada.

26
00:01:05,860 --> 00:01:08,160
‫Assim, funções que são chamadas assim

27
00:01:08,160 --> 00:01:11,700
‫que algum trabalho é concluído em algum momento no futuro.

28
00:01:11,700 --> 00:01:12,960
‫Lembre-se disso?

29
00:01:12,960 --> 00:01:15,310
‫E funciona assim porque o Node

30
00:01:15,310 --> 00:01:17,750
‫usa uma arquitetura acionada por evento, que

31
00:01:17,750 --> 00:01:20,480
‫é algo sobre o qual falaremos em um

32
00:01:20,480 --> 00:01:22,100
‫dos próximos vídeos.

33
00:01:22,100 --> 00:01:24,180
‫Mas o que você precisa saber

34
00:01:24,180 --> 00:01:26,020
‫por enquanto é que coisas

35
00:01:26,020 --> 00:01:31,020
‫como nosso aplicativo recebendo uma solicitação HTTP em nosso servidor ou um temporizador expirando

36
00:01:31,130 --> 00:01:34,860
‫ou um arquivo acabando de ser lido, tudo isso emitirá eventos

37
00:01:34,860 --> 00:01:37,350
‫assim que terminar seu trabalho, e nosso

38
00:01:37,350 --> 00:01:40,150
‫evento loop irá então pegar esses eventos e

39
00:01:40,150 --> 00:01:41,880
‫chamar as funções

40
00:01:41,880 --> 00:01:44,750
‫de retorno de chamada associadas a cada evento.

41
00:01:44,750 --> 00:01:46,520
‫Ok, faz sentido?

42
00:01:46,520 --> 00:01:49,680
‫Portanto, novamente, o loop de eventos recebe eventos

43
00:01:49,680 --> 00:01:51,800
‫cada vez que algo importante acontece

44
00:01:51,800 --> 00:01:54,440
‫e, então, chamará os callbacks necessários, como

45
00:01:54,440 --> 00:01:56,443
‫definimos em nosso código.

46
00:01:57,300 --> 00:01:59,690
‫Portanto, em resumo, costuma-se dizer que

47
00:01:59,690 --> 00:02:02,600
‫o loop de eventos faz a orquestração, o

48
00:02:02,600 --> 00:02:05,310
‫que significa simplesmente que ele recebe eventos, chama

49
00:02:05,310 --> 00:02:07,330
‫suas funções de retorno de

50
00:02:07,330 --> 00:02:11,290
‫chamada e descarrega as tarefas mais caras para o pool de threads.

51
00:02:11,290 --> 00:02:14,670
‫Agora, como tudo isso realmente funciona nos bastidores?

52
00:02:14,670 --> 00:02:17,960
‫Em que ordem esses callbacks são executados?

53
00:02:17,960 --> 00:02:20,543
‫Bem, é isso que vamos descobrir a seguir.

54
00:02:21,460 --> 00:02:24,630
‫Portanto, lembre-se, quando iniciamos nosso aplicativo Node, o loop

55
00:02:24,630 --> 00:02:27,430
‫de eventos começa a ser executado imediatamente.

56
00:02:27,430 --> 00:02:29,720
‫Agora, o loop de eventos tem

57
00:02:29,720 --> 00:02:32,330
‫várias fases, e cada fase tem uma

58
00:02:32,330 --> 00:02:35,060
‫fila de callback, que são os callbacks provenientes

59
00:02:35,060 --> 00:02:36,690
‫dos eventos que o

60
00:02:36,690 --> 00:02:39,830
‫loop de eventos recebe, conforme falamos no último slide.

61
00:02:39,830 --> 00:02:41,830
‫Agora, em alguns lugares você vai ler

62
00:02:41,830 --> 00:02:45,520
‫que existe apenas uma fila de retorno de chamada ou uma fila de eventos,

63
00:02:45,520 --> 00:02:49,290
‫mas na verdade, como eu disse, o loop de eventos tem muitas fases em

64
00:02:49,290 --> 00:02:52,290
‫que cada fase tem sua própria fila de retorno de chamada.

65
00:02:52,290 --> 00:02:56,090
‫Portanto, vamos agora dar uma olhada nas quatro fases mais importantes.

66
00:02:56,090 --> 00:02:58,090
‫Existem uma ou duas outras fases que

67
00:02:58,090 --> 00:02:59,890
‫são usadas internamente pelo Node,

68
00:02:59,890 --> 00:03:01,360
‫mas não são tão

69
00:03:01,360 --> 00:03:03,530
‫importantes e não vou falar sobre elas.

70
00:03:03,530 --> 00:03:05,230
‫Portanto, a primeira

71
00:03:05,230 --> 00:03:07,860
‫fase cuida de callbacks de temporizadores

72
00:03:07,860 --> 00:03:10,880
‫expirados, por exemplo, da função setTimeout ().

73
00:03:10,880 --> 00:03:13,210
‫Portanto, se houver funções de retorno de chamada de

74
00:03:13,210 --> 00:03:15,750
‫temporizadores que acabaram de expirar, essas são as primeiras

75
00:03:15,750 --> 00:03:18,010
‫a serem processadas pelo loop de eventos.

76
00:03:18,010 --> 00:03:21,040
‫Se um temporizador expirar mais tarde durante o tempo em

77
00:03:21,040 --> 00:03:23,370
‫que uma das outras fases estiver

78
00:03:23,370 --> 00:03:26,860
‫sendo processada, bem, o retorno de chamada desse temporizador só será

79
00:03:26,860 --> 00:03:30,450
‫chamado assim que o loop de evento voltar a esta primeira fase.

80
00:03:30,450 --> 00:03:31,580
‫Faz sentido?

81
00:03:31,580 --> 00:03:34,520
‫E funciona assim em todas as quatro fases.

82
00:03:34,520 --> 00:03:37,250
‫Assim, os callbacks em cada fila são

83
00:03:37,250 --> 00:03:40,810
‫processados um a um até que não haja mais nenhum na

84
00:03:40,810 --> 00:03:44,630
‫fila, e só então o loop de eventos entrará na próxima fase.

85
00:03:44,630 --> 00:03:49,180
‫Em seguida, temos o polling de I / O e a execução de callbacks de I / O.

86
00:03:49,180 --> 00:03:52,840
‫E, novamente, lembre-se de que I / O significa entrada / saída.

87
00:03:52,840 --> 00:03:56,040
‫Portanto, a pesquisa basicamente significa procurar novos eventos de E /

88
00:03:56,040 --> 00:03:58,060
‫S que estão prontos para serem

89
00:03:58,060 --> 00:04:00,890
‫processados e colocá-los na fila de retorno de chamada.

90
00:04:00,890 --> 00:04:04,110
‫E lembre-se de que, no contexto de um aplicativo

91
00:04:04,110 --> 00:04:08,710
‫Node, I / O significa principalmente coisas como rede e acesso a

92
00:04:08,710 --> 00:04:12,150
‫arquivos e, portanto, é nesta fase que provavelmente 99%

93
00:04:12,150 --> 00:04:14,270
‫do nosso código é

94
00:04:14,270 --> 00:04:16,640
‫executado, simplesmente porque em um aplicativo

95
00:04:16,640 --> 00:04:20,500
‫Node típico, a maior parte do que precisamos fazer está relacionado

96
00:04:20,500 --> 00:04:23,170
‫à rede e também, acesso a arquivos.

97
00:04:23,170 --> 00:04:26,490
‫A próxima fase é para retornos de chamada setImmediate e setImmediate

98
00:04:26,490 --> 00:04:29,250
‫é um tipo especial de cronômetro que podemos

99
00:04:29,250 --> 00:04:32,810
‫usar se quisermos processar retornos de chamada imediatamente após a pesquisa de

100
00:04:32,810 --> 00:04:36,130
‫E / S e a fase de execução, o que pode

101
00:04:36,130 --> 00:04:39,173
‫ser importante em alguns casos de uso mais avançados.

102
00:04:40,110 --> 00:04:40,943
‫Tudo bem.

103
00:04:40,943 --> 00:04:44,940
‫E, por fim, a quarta fase é para retornos de chamada fechados, que,

104
00:04:44,940 --> 00:04:47,530
‫novamente, não são tão importantes para nós, mas

105
00:04:47,530 --> 00:04:50,820
‫coloquei isso aqui de qualquer maneira por uma questão de integridade.

106
00:04:50,820 --> 00:04:54,450
‫Basicamente, nesta fase, todos os eventos de fechamento são processados,

107
00:04:54,450 --> 00:04:58,920
‫por exemplo, para o encerramento de um servidor web ou de um WebSocket.

108
00:04:58,920 --> 00:05:01,920
‫Portanto, essas são as quatro fases do loop de

109
00:05:01,920 --> 00:05:05,400
‫eventos, mas além dessas quatro filas de retorno de chamada

110
00:05:05,400 --> 00:05:08,330
‫que acabamos de ver, há também duas

111
00:05:08,330 --> 00:05:11,600
‫outras filas, a fila nextTick () e a outra

112
00:05:11,600 --> 00:05:14,780
‫fila de microtarefas, que é principalmente para promessas resolvidas.

113
00:05:14,780 --> 00:05:16,890
‫Se você não estiver familiarizado

114
00:05:16,890 --> 00:05:20,240
‫com as promessas, falaremos sobre elas um pouco mais adiante.

115
00:05:20,240 --> 00:05:22,620
‫De qualquer forma, se houver callbacks em

116
00:05:22,620 --> 00:05:24,750
‫uma dessas duas filas para serem

117
00:05:24,750 --> 00:05:27,840
‫processados, eles serão executados logo após o término da fase

118
00:05:27,840 --> 00:05:30,250
‫atual do loop de eventos, em vez de

119
00:05:30,250 --> 00:05:32,380
‫esperar que todo o loop termine.

120
00:05:32,380 --> 00:05:33,370
‫OK?

121
00:05:33,370 --> 00:05:36,680
‫Ou seja, após cada uma dessas quatro

122
00:05:36,680 --> 00:05:40,340
‫fases, se houver callbacks nessas duas filas especiais,

123
00:05:40,340 --> 00:05:42,880
‫eles serão executados imediatamente.

124
00:05:42,880 --> 00:05:46,030
‫Agora, por exemplo, imagine que uma promessa resolve e retorna

125
00:05:46,030 --> 00:05:49,730
‫alguns dados de uma chamada de API enquanto o retorno de

126
00:05:49,730 --> 00:05:52,690
‫chamada de um cronômetro expirado está em execução.

127
00:05:52,690 --> 00:05:56,050
‫Portanto, neste caso, o retorno de chamada da promessa será

128
00:05:56,050 --> 00:05:59,230
‫executado logo após o término daquele do temporizador.

129
00:05:59,230 --> 00:06:00,490
‫OK?

130
00:06:00,490 --> 00:06:03,480
‫E a mesma lógica também se aplica à fila nextTick (),

131
00:06:03,480 --> 00:06:05,290
‫sobre a qual ainda não falamos.

132
00:06:05,290 --> 00:06:09,060
‫Então, basicamente, processar o nextTick () é uma função que podemos

133
00:06:09,060 --> 00:06:11,610
‫usar quando realmente, realmente precisamos executar um determinado

134
00:06:11,610 --> 00:06:13,740
‫retorno de chamada logo após

135
00:06:13,740 --> 00:06:16,290
‫a fase de loop de evento atual.

136
00:06:16,290 --> 00:06:18,810
‫É um pouco semelhante a setImmediate, com a diferença de

137
00:06:18,810 --> 00:06:21,540
‫que setImmediate só é executado após a fase de retorno

138
00:06:21,540 --> 00:06:23,400
‫de chamada de E / S.

139
00:06:23,400 --> 00:06:24,600
‫O que é

140
00:06:24,600 --> 00:06:27,930
‫semelhante, porém, é que ambos são para casos de uso

141
00:06:27,930 --> 00:06:30,080
‫realmente avançados e provavelmente nem precisaremos deles

142
00:06:30,080 --> 00:06:31,580
‫ao longo deste curso.

143
00:06:31,580 --> 00:06:34,660
‫Mas de qualquer forma, eu queria incluir essas coisas mais

144
00:06:34,660 --> 00:06:36,700
‫complexas aqui também para que você tenha

145
00:06:36,700 --> 00:06:38,940
‫as ferramentas de que precisa se realmente

146
00:06:38,940 --> 00:06:42,980
‫precisar se aprofundar no Node. js se você quiser.

147
00:06:42,980 --> 00:06:46,210
‫Tudo bem, e com isso, na verdade terminamos um

148
00:06:46,210 --> 00:06:50,360
‫tick do loop de eventos, e um tick é basicamente apenas um

149
00:06:50,360 --> 00:06:51,580
‫ciclo neste loop.

150
00:06:51,580 --> 00:06:54,840
‫Portanto, agora é hora de decidir se o loop deve

151
00:06:54,840 --> 00:06:58,520
‫continuar para o próximo tick ou se o programa deve ser encerrado.

152
00:06:58,520 --> 00:07:00,720
‫E como o Node faz isso?

153
00:07:00,720 --> 00:07:02,310
‫Bem, é muito simples.

154
00:07:02,310 --> 00:07:05,100
‫O Node simplesmente verifica se há algum

155
00:07:05,100 --> 00:07:08,440
‫temporizador ou tarefa de E / S ainda em execução

156
00:07:08,440 --> 00:07:12,180
‫em segundo plano e, se não houver, ele sairá do aplicativo.

157
00:07:12,180 --> 00:07:15,430
‫Mas se houver algum temporizador ou tarefa de E / S

158
00:07:15,430 --> 00:07:17,870
‫pendentes, bem, ele continuará executando o loop

159
00:07:17,870 --> 00:07:20,500
‫de eventos e irá direto para o próximo tick.

160
00:07:20,500 --> 00:07:22,030
‫Então, por exemplo, quando ouvimos

161
00:07:22,030 --> 00:07:24,740
‫as solicitações HTTP de entrada como fizemos em nosso

162
00:07:24,740 --> 00:07:27,770
‫projeto de farm de Nó na seção anterior, estávamos basicamente executando

163
00:07:27,770 --> 00:07:30,600
‫uma tarefa de E / S e é por isso

164
00:07:30,600 --> 00:07:32,320
‫que o loop de evento e,

165
00:07:32,320 --> 00:07:34,640
‫portanto, o Nó. js, continue

166
00:07:34,640 --> 00:07:38,600
‫executando e escutando as novas solicitações de HTTP que

167
00:07:38,600 --> 00:07:41,920
‫chegam, em vez de apenas sair do aplicativo.

168
00:07:41,920 --> 00:07:44,450
‫Além disso, quando estamos escrevendo ou lendo um

169
00:07:44,450 --> 00:07:47,480
‫arquivo em segundo plano, isso também é uma tarefa de

170
00:07:47,480 --> 00:07:50,210
‫E / S e, portanto, faz sentido que o

171
00:07:50,210 --> 00:07:53,260
‫aplicativo não saia enquanto estiver trabalhando com aquele arquivo, certo?

172
00:07:53,260 --> 00:07:55,780
‫Ok, e isso é basicamente o que você deve saber

173
00:07:55,780 --> 00:07:57,930
‫sobre o Node. loop de eventos js.

174
00:07:57,930 --> 00:08:00,260
‫Se precisar de mais detalhes do que isso,

175
00:08:00,260 --> 00:08:01,760
‫bem, você sempre pode

176
00:08:01,760 --> 00:08:04,860
‫tentar ler a documentação oficial do Node, que deve ser bem

177
00:08:04,860 --> 00:08:07,060
‫fácil de entender neste ponto, agora que você

178
00:08:07,060 --> 00:08:10,570
‫já entende a maior parte do loop de eventos de qualquer maneira.

179
00:08:10,570 --> 00:08:12,830
‫E eu só quero enfatizar que

180
00:08:12,830 --> 00:08:15,940
‫é muito, muito importante que você entenda corretamente o loop

181
00:08:15,940 --> 00:08:18,280
‫de eventos para que possa escrever seu

182
00:08:18,280 --> 00:08:21,390
‫próprio código de desempenho e também depurar seu próprio código

183
00:08:21,390 --> 00:08:24,173
‫quando algo der errado de uma maneira inesperada.

184
00:08:25,720 --> 00:08:27,770
‫E agora, para terminar, vamos revisar algumas das

185
00:08:27,770 --> 00:08:29,810
‫coisas sobre as quais falamos aqui.

186
00:08:29,810 --> 00:08:32,490
‫Então, em poucas palavras, a coisa mais importante que eu

187
00:08:32,490 --> 00:08:34,620
‫quero que você entenda desta palestra, e talvez

188
00:08:34,620 --> 00:08:36,740
‫de todo o curso, é que o loop

189
00:08:36,740 --> 00:08:38,560
‫de eventos é o que torna a

190
00:08:38,560 --> 00:08:41,630
‫programação assíncrona possível no Node. js, tornando-o o

191
00:08:41,630 --> 00:08:45,190
‫recurso mais importante no projeto e na criação

192
00:08:45,190 --> 00:08:47,580
‫do Node. js completamente

193
00:08:47,580 --> 00:08:49,050
‫diferente de outras plataformas.

194
00:08:49,050 --> 00:08:51,600
‫Ele cuida de todos os eventos de

195
00:08:51,600 --> 00:08:55,120
‫entrada e realiza a orquestração transferindo tarefas mais pesadas para o

196
00:08:55,120 --> 00:08:58,840
‫pool de threads e fazendo o trabalho mais simples por conta própria.

197
00:08:58,840 --> 00:09:01,520
‫Além disso, lembre-se de que precisamos do loop

198
00:09:01,520 --> 00:09:05,260
‫de eventos porque em Node. js tudo funciona em um

199
00:09:05,260 --> 00:09:07,260
‫único thread, e assim, você pode

200
00:09:07,260 --> 00:09:11,230
‫ter milhares ou milhões de usuários acessando o mesmo thread ao mesmo tempo.

201
00:09:11,230 --> 00:09:13,690
‫Isso torna o Node tão leve e escalável,

202
00:09:13,690 --> 00:09:16,290
‫mas ao mesmo tempo, vem com o perigo

203
00:09:16,290 --> 00:09:17,930
‫de bloquear nosso único

204
00:09:17,930 --> 00:09:20,140
‫thread, o que tornaria o aplicativo

205
00:09:20,140 --> 00:09:25,140
‫inteiro lento ou até mesmo pararia para todos os seus usuários acessarem o aplicativo, certo?

206
00:09:25,340 --> 00:09:28,110
‫Agora, em outras linguagens como PHP em

207
00:09:28,110 --> 00:09:31,300
‫execução em um servidor Apache, basicamente, um novo thread

208
00:09:31,300 --> 00:09:35,200
‫é criado para cada novo usuário, o que consome muito mais recursos.

209
00:09:35,200 --> 00:09:37,180
‫Mas por outro lado, não

210
00:09:37,180 --> 00:09:39,160
‫há perigo de bloqueio, certo?

211
00:09:39,160 --> 00:09:41,430
‫Então, todo esse modelo torna um pouco

212
00:09:41,430 --> 00:09:44,340
‫mais fácil usar o PHP para iniciantes, mas é

213
00:09:44,340 --> 00:09:46,540
‫claro, ele vem com suas próprias

214
00:09:46,540 --> 00:09:48,890
‫desvantagens, que não vou abordar neste ponto.

215
00:09:48,890 --> 00:09:50,690
‫De qualquer forma, deixe-me

216
00:09:50,690 --> 00:09:54,860
‫lembrá-lo novamente de que é sua responsabilidade não bloquear o loop de

217
00:09:54,860 --> 00:09:58,150
‫eventos e, portanto, aqui estão algumas diretrizes para isso.

218
00:09:58,150 --> 00:10:00,490
‫Em primeiro lugar, não use as

219
00:10:00,490 --> 00:10:02,850
‫versões de sincronização de funções nos módulos fs,

220
00:10:02,850 --> 00:10:06,450
‫crypto ou zlib em suas funções de retorno de chamada, certo?

221
00:10:06,450 --> 00:10:09,210
‫Então, em nosso primeiro projeto, nós realmente usamos a

222
00:10:09,210 --> 00:10:12,610
‫versão síncrona, mas ela estava no código de nível superior, portanto,

223
00:10:12,610 --> 00:10:15,000
‫fora de qualquer retorno de chamada.

224
00:10:15,000 --> 00:10:18,520
‫E como esse código é executado antes mesmo do loop

225
00:10:18,520 --> 00:10:22,200
‫de eventos começar, bem, não é problema usar a versão síncrona aí.

226
00:10:22,200 --> 00:10:24,910
‫Além disso, e isso provavelmente é bastante

227
00:10:24,910 --> 00:10:28,140
‫óbvio, não execute cálculos muito complexos no loop de eventos.

228
00:10:28,140 --> 00:10:29,730
‫Então, coisas como processar

229
00:10:29,730 --> 00:10:33,890
‫milhões de números em loops dentro de loops, ou algo assim.

230
00:10:33,890 --> 00:10:37,550
‫Em seguida, tome cuidado com o JSON em objetos muito

231
00:10:37,550 --> 00:10:40,480
‫grandes porque, em algum ponto, pode começar

232
00:10:40,480 --> 00:10:43,440
‫a demorar muito para analisar ou sequenciar o JSON.

233
00:10:43,440 --> 00:10:47,170
‫E, finalmente, não use expressões regulares muito complexas, por

234
00:10:47,170 --> 00:10:49,840
‫exemplo, com vários quantificadores aninhados ou

235
00:10:49,840 --> 00:10:52,130
‫referências anteriores, porque, novamente, eles

236
00:10:52,130 --> 00:10:54,810
‫podem demorar mais do que o esperado.

237
00:10:54,810 --> 00:10:56,680
‫Essas são, é claro, apenas algumas

238
00:10:56,680 --> 00:10:59,700
‫diretrizes de alto nível, mas elas o ajudarão a começar

239
00:10:59,700 --> 00:11:00,803
‫no caminho certo.

240
00:11:01,650 --> 00:11:03,490
‫Agora, existem algumas soluções potenciais

241
00:11:03,490 --> 00:11:06,390
‫para esses problemas de bloqueio, como descarregar manualmente para

242
00:11:06,390 --> 00:11:09,750
‫o pool de threads ou usar processos filhos, e podemos falar

243
00:11:09,750 --> 00:11:12,070
‫sobre isso no final do curso ou

244
00:11:12,070 --> 00:11:14,370
‫em algum momento no futuro, mas por

245
00:11:14,370 --> 00:11:17,460
‫agora, é importante que você entende e segue este conselho

246
00:11:17,460 --> 00:11:20,110
‫de realmente não bloquear o loop de eventos.

247
00:11:20,110 --> 00:11:21,600
‫Tudo bem.

248
00:11:21,600 --> 00:11:24,520
‫A seguir, vou dar um pequeno exemplo para

249
00:11:24,520 --> 00:11:25,990
‫mostrar algumas das

250
00:11:25,990 --> 00:11:27,640
‫coisas que falamos na prática.