1
00:00:01,150 --> 00:00:02,580
‫Istruttore: Bentornato.

2
00:00:02,580 --> 00:00:05,000
‫Impariamo ora tutto sul ciclo degli eventi, che

3
00:00:05,000 --> 00:00:08,150
‫è il cuore di Node. js architettura.

4
00:00:08,150 --> 00:00:10,580
‫E questa è probabilmente la lezione

5
00:00:10,580 --> 00:00:13,500
‫più importante di questa sezione, quindi assicurati di aver

6
00:00:13,500 --> 00:00:16,510
‫compreso davvero tutto ciò che ti mostro durante questo video.

7
00:00:16,510 --> 00:00:17,813
‫Quindi iniziamo.

8
00:00:18,800 --> 00:00:21,880
‫Quindi, ecco un diagramma simile all'ultima lezione in

9
00:00:21,880 --> 00:00:25,170
‫modo che sappiamo esattamente di cosa stiamo parlando qui.

10
00:00:25,170 --> 00:00:28,240
‫Quindi, siamo ancora in un processo Node nel singolo thread in

11
00:00:28,240 --> 00:00:30,810
‫cui viene eseguito il ciclo degli eventi, ok?

12
00:00:30,810 --> 00:00:32,530
‫Ora, la prima cosa che devi

13
00:00:32,530 --> 00:00:34,750
‫sapere è che il ciclo degli eventi è il

14
00:00:34,750 --> 00:00:36,350
‫punto in cui viene eseguito

15
00:00:36,350 --> 00:00:39,550
‫tutto il codice dell'applicazione che si trova all'interno delle funzioni di callback.

16
00:00:39,550 --> 00:00:43,640
‫Quindi, in pratica, tutto il codice che non è codice di primo livello verrà

17
00:00:43,640 --> 00:00:45,250
‫eseguito nel ciclo degli eventi.

18
00:00:45,250 --> 00:00:48,450
‫Alcune parti potrebbero essere scaricate nel pool di thread come

19
00:00:48,450 --> 00:00:50,140
‫abbiamo visto nell'ultima lezione, ma

20
00:00:50,140 --> 00:00:53,430
‫è il ciclo degli eventi che si occupa di tutto questo.

21
00:00:53,430 --> 00:00:56,370
‫Come ho detto prima, è davvero

22
00:00:56,370 --> 00:00:58,360
‫il cuore dell'architettura Node.

23
00:00:58,360 --> 00:01:01,660
‫Ok, ora, come ho detto più volte nella prima parte

24
00:01:01,660 --> 00:01:04,300
‫del corso, Node. js è tutto costruito

25
00:01:04,300 --> 00:01:05,860
‫attorno alle funzioni di callback.

26
00:01:05,860 --> 00:01:08,160
‫Quindi, funzioni che vengono chiamate

27
00:01:08,160 --> 00:01:11,700
‫non appena un lavoro viene terminato in futuro.

28
00:01:11,700 --> 00:01:12,960
‫Ricordati che?

29
00:01:12,960 --> 00:01:15,310
‫E funziona in questo modo perché

30
00:01:15,310 --> 00:01:17,750
‫Node utilizza un'architettura attivata da eventi, che

31
00:01:17,750 --> 00:01:20,480
‫è qualcosa di cui parleremo in uno

32
00:01:20,480 --> 00:01:22,100
‫dei prossimi video.

33
00:01:22,100 --> 00:01:24,180
‫Ma quello che devi sapere per

34
00:01:24,180 --> 00:01:26,020
‫ora è che cose come

35
00:01:26,020 --> 00:01:31,020
‫la nostra applicazione che riceve una richiesta HTTP sul nostro server o un timer in

36
00:01:31,130 --> 00:01:34,860
‫scadenza o un file che sta finendo di leggere, tutti questi

37
00:01:34,860 --> 00:01:37,350
‫emetteranno eventi non appena avranno finito con il

38
00:01:37,350 --> 00:01:40,150
‫loro lavoro, e il nostro evento loop prenderà

39
00:01:40,150 --> 00:01:41,880
‫quindi questi eventi e

40
00:01:41,880 --> 00:01:44,750
‫chiamerà le funzioni di callback associate a ciascun evento.

41
00:01:44,750 --> 00:01:46,520
‫Ok, ha senso?

42
00:01:46,520 --> 00:01:49,680
‫Quindi, di nuovo, il ciclo degli eventi riceve eventi

43
00:01:49,680 --> 00:01:51,800
‫ogni volta che accade qualcosa di

44
00:01:51,800 --> 00:01:54,440
‫importante e quindi chiamerà i callback necessari come

45
00:01:54,440 --> 00:01:56,443
‫definiti nel nostro codice.

46
00:01:57,300 --> 00:01:59,690
‫Quindi, in sintesi, di solito si

47
00:01:59,690 --> 00:02:02,600
‫dice che il ciclo di eventi esegue l'orchestrazione,

48
00:02:02,600 --> 00:02:05,310
‫il che significa semplicemente che riceve eventi,

49
00:02:05,310 --> 00:02:07,330
‫chiama le loro funzioni di

50
00:02:07,330 --> 00:02:11,290
‫callback e scarica le attività più costose nel pool di thread.

51
00:02:11,290 --> 00:02:14,670
‫Ora, come funziona tutto questo dietro le quinte?

52
00:02:14,670 --> 00:02:17,960
‫In quale ordine vengono eseguiti questi callback?

53
00:02:17,960 --> 00:02:20,543
‫Bene, questo è quello che scopriremo dopo.

54
00:02:21,460 --> 00:02:24,630
‫Quindi, ricorda, quando avviamo la nostra applicazione Node, il ciclo

55
00:02:24,630 --> 00:02:27,430
‫degli eventi inizia a essere eseguito immediatamente.

56
00:02:27,430 --> 00:02:29,720
‫Ora, il loop di eventi ha

57
00:02:29,720 --> 00:02:32,330
‫più fasi e ogni fase ha una coda

58
00:02:32,330 --> 00:02:35,060
‫di callback, che sono i callback provenienti dagli

59
00:02:35,060 --> 00:02:36,690
‫eventi che riceve il

60
00:02:36,690 --> 00:02:39,830
‫loop di eventi, proprio come abbiamo detto nell'ultima diapositiva.

61
00:02:39,830 --> 00:02:41,830
‫Ora, in alcuni punti leggerai che

62
00:02:41,830 --> 00:02:45,520
‫c'è solo una coda di callback o una coda di eventi, ma

63
00:02:45,520 --> 00:02:49,290
‫in effetti, come ho detto, il ciclo di eventi ha molte fasi in

64
00:02:49,290 --> 00:02:52,290
‫cui ogni fase ha la sua coda di callback.

65
00:02:52,290 --> 00:02:56,090
‫Quindi, diamo ora uno sguardo alle quattro fasi più importanti.

66
00:02:56,090 --> 00:02:58,090
‫Ci sono una o due altre fasi

67
00:02:58,090 --> 00:02:59,890
‫che vengono utilizzate internamente da

68
00:02:59,890 --> 00:03:01,360
‫Node, ma queste non

69
00:03:01,360 --> 00:03:03,530
‫sono così importanti e non ne parlerò.

70
00:03:03,530 --> 00:03:05,230
‫Quindi, la prima

71
00:03:05,230 --> 00:03:07,860
‫fase si occupa dei callback dei

72
00:03:07,860 --> 00:03:10,880
‫timer scaduti, ad esempio, dalla funzione setTimeout().

73
00:03:10,880 --> 00:03:13,210
‫Quindi, se ci sono funzioni di callback da

74
00:03:13,210 --> 00:03:15,750
‫timer che sono appena scaduti, queste sono le prime

75
00:03:15,750 --> 00:03:18,010
‫ad essere elaborate dal ciclo di eventi.

76
00:03:18,010 --> 00:03:21,040
‫Se un timer scade più tardi durante il tempo

77
00:03:21,040 --> 00:03:23,370
‫in cui viene elaborata una delle

78
00:03:23,370 --> 00:03:26,860
‫altre fasi, allora il callback di quel timer verrà chiamato solo

79
00:03:26,860 --> 00:03:30,450
‫non appena il ciclo di eventi torna a questa prima fase.

80
00:03:30,450 --> 00:03:31,580
‫Ha senso?

81
00:03:31,580 --> 00:03:34,520
‫E funziona così in tutte e quattro le fasi.

82
00:03:34,520 --> 00:03:37,250
‫Quindi, i callback in ogni coda vengono elaborati

83
00:03:37,250 --> 00:03:40,810
‫uno per uno fino a quando non ne rimangono più in

84
00:03:40,810 --> 00:03:44,630
‫coda e solo allora il ciclo degli eventi entrerà nella fase successiva.

85
00:03:44,630 --> 00:03:49,180
‫Successivamente, abbiamo il polling I/O e l'esecuzione di callback I/O.

86
00:03:49,180 --> 00:03:52,840
‫E ancora, ricorda che I/O sta per input/output.

87
00:03:52,840 --> 00:03:56,040
‫Quindi, polling significa fondamentalmente cercare nuovi eventi di

88
00:03:56,040 --> 00:03:58,060
‫I/O pronti per essere

89
00:03:58,060 --> 00:04:00,890
‫elaborati e inserirli nella coda di callback.

90
00:04:00,890 --> 00:04:04,110
‫E ricorda che nel contesto di un'applicazione Node, I/O

91
00:04:04,110 --> 00:04:08,710
‫significa principalmente cose come la rete e l'accesso ai file, quindi è

92
00:04:08,710 --> 00:04:12,150
‫in questa fase in cui probabilmente il 99% del

93
00:04:12,150 --> 00:04:14,270
‫nostro codice viene eseguito,

94
00:04:14,270 --> 00:04:16,640
‫semplicemente perché in una tipica app

95
00:04:16,640 --> 00:04:20,500
‫Node, la maggior parte di ciò che dobbiamo fare è relativo

96
00:04:20,500 --> 00:04:23,170
‫alla rete e anche all'accesso ai file.

97
00:04:23,170 --> 00:04:26,490
‫La fase successiva è per i callback setImmediate e setImmediate

98
00:04:26,490 --> 00:04:29,250
‫è un tipo speciale di timer che

99
00:04:29,250 --> 00:04:32,810
‫possiamo usare se vogliamo elaborare i callback immediatamente dopo la

100
00:04:32,810 --> 00:04:36,130
‫fase di polling ed esecuzione di I/O, che può

101
00:04:36,130 --> 00:04:39,173
‫essere importante in alcuni casi d'uso più avanzati.

102
00:04:40,110 --> 00:04:40,943
‫Va bene.

103
00:04:40,943 --> 00:04:44,940
‫E infine, la quarta fase è per i richiami ravvicinati, che, ancora

104
00:04:44,940 --> 00:04:47,530
‫una volta, non sono così importanti per

105
00:04:47,530 --> 00:04:50,820
‫noi, ma lo metto comunque qui per motivi di completezza.

106
00:04:50,820 --> 00:04:54,450
‫Fondamentalmente, in questa fase, vengono elaborati tutti gli eventi di

107
00:04:54,450 --> 00:04:58,920
‫chiusura, ad esempio per l'arresto di un server Web o di un WebSocket.

108
00:04:58,920 --> 00:05:01,920
‫Quindi, queste sono le quattro fasi nel ciclo degli

109
00:05:01,920 --> 00:05:05,400
‫eventi, ma oltre a queste quattro code di callback che

110
00:05:05,400 --> 00:05:08,330
‫abbiamo appena visto, in realtà ci sono

111
00:05:08,330 --> 00:05:11,600
‫anche altre due code, la coda nextTick() e l'altra coda

112
00:05:11,600 --> 00:05:14,780
‫di microtask, che è principalmente per le promesse risolte.

113
00:05:14,780 --> 00:05:16,890
‫Se non hai familiarità con

114
00:05:16,890 --> 00:05:20,240
‫le promesse, ne parleremo un po' in una sezione successiva.

115
00:05:20,240 --> 00:05:22,620
‫Ad ogni modo, se sono presenti callback

116
00:05:22,620 --> 00:05:24,750
‫in una di queste due code

117
00:05:24,750 --> 00:05:27,840
‫da elaborare, verranno eseguite subito dopo la fine della

118
00:05:27,840 --> 00:05:30,250
‫fase corrente del ciclo di eventi invece

119
00:05:30,250 --> 00:05:32,380
‫di attendere la fine dell'intero ciclo.

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

121
00:05:33,370 --> 00:05:36,680
‫Quindi, in altre parole, dopo ciascuna di queste

122
00:05:36,680 --> 00:05:40,340
‫quattro fasi, se ci sono delle richiamate in queste

123
00:05:40,340 --> 00:05:42,880
‫due code speciali, verranno eseguite immediatamente.

124
00:05:42,880 --> 00:05:46,030
‫Ora, ad esempio, immagina che una promessa si risolva

125
00:05:46,030 --> 00:05:49,730
‫e restituisca alcuni dati da una chiamata API mentre è in

126
00:05:49,730 --> 00:05:52,690
‫esecuzione il callback di un timer scaduto.

127
00:05:52,690 --> 00:05:56,050
‫Quindi, in questo caso, la richiamata della promessa verrà eseguita

128
00:05:56,050 --> 00:05:59,230
‫subito dopo la fine di quella del timer.

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

130
00:06:00,490 --> 00:06:03,480
‫E la stessa logica si applica anche alla coda nextTick(),

131
00:06:03,480 --> 00:06:05,290
‫di cui non abbiamo ancora parlato.

132
00:06:05,290 --> 00:06:09,060
‫Quindi, fondamentalmente, process the nextTick() è una funzione che possiamo usare

133
00:06:09,060 --> 00:06:11,610
‫quando abbiamo davvero, davvero bisogno di eseguire

134
00:06:11,610 --> 00:06:13,740
‫un certo callback subito dopo

135
00:06:13,740 --> 00:06:16,290
‫la fase del ciclo di eventi corrente.

136
00:06:16,290 --> 00:06:18,810
‫È un po' simile a setImmediate, con

137
00:06:18,810 --> 00:06:21,540
‫la differenza che setImmediate viene eseguito solo dopo la

138
00:06:21,540 --> 00:06:23,400
‫fase di callback di I/O.

139
00:06:23,400 --> 00:06:24,600
‫Ciò che è

140
00:06:24,600 --> 00:06:27,930
‫simile, tuttavia, è che entrambi sono per casi d'uso davvero

141
00:06:27,930 --> 00:06:30,080
‫avanzati e probabilmente non ne avremo nemmeno

142
00:06:30,080 --> 00:06:31,580
‫bisogno durante questo corso.

143
00:06:31,580 --> 00:06:34,660
‫Ma comunque, volevo includere anche queste cose più complesse qui

144
00:06:34,660 --> 00:06:36,700
‫in modo da avere gli strumenti di

145
00:06:36,700 --> 00:06:38,940
‫cui hai bisogno se hai davvero bisogno di

146
00:06:38,940 --> 00:06:42,980
‫scavare a fondo in Node. js se vuoi.

147
00:06:42,980 --> 00:06:46,210
‫Bene, e con ciò, abbiamo effettivamente terminato un tick

148
00:06:46,210 --> 00:06:50,360
‫del ciclo degli eventi, e un tick è fondamentalmente solo un ciclo

149
00:06:50,360 --> 00:06:51,580
‫in questo ciclo.

150
00:06:51,580 --> 00:06:54,840
‫Quindi, ora è il momento di decidere se il ciclo

151
00:06:54,840 --> 00:06:58,520
‫deve continuare fino al tick successivo o se il programma deve uscire.

152
00:06:58,520 --> 00:07:00,720
‫E come fa Node a farlo?

153
00:07:00,720 --> 00:07:02,310
‫Bene, è molto semplice.

154
00:07:02,310 --> 00:07:05,100
‫Il nodo controlla semplicemente se ci sono

155
00:07:05,100 --> 00:07:08,440
‫timer o attività di I/O che sono ancora in

156
00:07:08,440 --> 00:07:12,180
‫esecuzione in background e, se non ce ne sono, uscirà dall'applicazione.

157
00:07:12,180 --> 00:07:15,430
‫Ma se ci sono timer o attività di I/O in sospeso,

158
00:07:15,430 --> 00:07:17,870
‫allora continuerà a eseguire il ciclo degli

159
00:07:17,870 --> 00:07:20,500
‫eventi e passerà direttamente al segno di spunta successivo.

160
00:07:20,500 --> 00:07:22,030
‫Quindi, ad esempio, quando

161
00:07:22,030 --> 00:07:24,740
‫ascoltiamo le richieste HTTP in entrata come abbiamo

162
00:07:24,740 --> 00:07:27,770
‫fatto nel nostro progetto Node farm in una sezione precedente,

163
00:07:27,770 --> 00:07:30,600
‫stavamo fondamentalmente eseguendo un'attività di I/O, ed è per

164
00:07:30,600 --> 00:07:32,320
‫questo che il ciclo degli eventi,

165
00:07:32,320 --> 00:07:34,640
‫e quindi, Node. js, continua

166
00:07:34,640 --> 00:07:38,600
‫a funzionare e continua ad ascoltare le nuove richieste

167
00:07:38,600 --> 00:07:41,920
‫HTTP in arrivo invece di uscire dall'applicazione.

168
00:07:41,920 --> 00:07:44,450
‫Inoltre, quando scriviamo o leggiamo un

169
00:07:44,450 --> 00:07:47,480
‫file in background, anche questa è un'attività di

170
00:07:47,480 --> 00:07:50,210
‫I/O, quindi ha senso che l'app non

171
00:07:50,210 --> 00:07:53,260
‫esca mentre sta lavorando con quel file, giusto?

172
00:07:53,260 --> 00:07:55,780
‫Ok, e questo è fondamentalmente ciò che dovresti

173
00:07:55,780 --> 00:07:57,930
‫sapere su Node. js ciclo di eventi.

174
00:07:57,930 --> 00:08:00,260
‫Se hai bisogno di ulteriori dettagli, beh,

175
00:08:00,260 --> 00:08:01,760
‫puoi sempre provare a

176
00:08:01,760 --> 00:08:04,860
‫leggere la documentazione ufficiale di Node, che dovrebbe essere abbastanza

177
00:08:04,860 --> 00:08:07,060
‫facile da capire a questo punto ora

178
00:08:07,060 --> 00:08:10,570
‫che hai già compreso la maggior parte del ciclo di eventi comunque.

179
00:08:10,570 --> 00:08:12,830
‫E voglio solo sottolineare che è

180
00:08:12,830 --> 00:08:15,940
‫davvero, davvero importante per te capire correttamente il ciclo degli

181
00:08:15,940 --> 00:08:18,280
‫eventi in modo da poter scrivere il

182
00:08:18,280 --> 00:08:21,390
‫tuo codice performante e anche eseguire il debug del tuo

183
00:08:21,390 --> 00:08:24,173
‫codice quando qualcosa va storto in un modo inaspettato.

184
00:08:25,720 --> 00:08:27,770
‫E ora, solo per finire, esaminiamo alcune delle

185
00:08:27,770 --> 00:08:29,810
‫cose di cui abbiamo parlato qui.

186
00:08:29,810 --> 00:08:32,490
‫Quindi, in poche parole, la cosa più importante che voglio

187
00:08:32,490 --> 00:08:34,620
‫che tu capisca da questa lezione, e forse

188
00:08:34,620 --> 00:08:36,740
‫da questo intero corso, è che il ciclo

189
00:08:36,740 --> 00:08:38,560
‫di eventi è ciò che rende possibile

190
00:08:38,560 --> 00:08:41,630
‫la programmazione asincrona in Node. js, rendendolo la

191
00:08:41,630 --> 00:08:45,190
‫caratteristica più importante nel design di Node e

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

193
00:08:47,580 --> 00:08:49,050
‫diverso da altre piattaforme.

194
00:08:49,050 --> 00:08:51,600
‫Si occupa di tutti gli eventi in

195
00:08:51,600 --> 00:08:55,120
‫arrivo ed esegue l'orchestrazione scaricando le attività più pesanti nel

196
00:08:55,120 --> 00:08:58,840
‫pool di thread e svolgendo da solo il lavoro più semplice.

197
00:08:58,840 --> 00:09:01,520
‫Inoltre, ricorda che abbiamo bisogno del ciclo degli

198
00:09:01,520 --> 00:09:05,260
‫eventi perché in Node. js tutto funziona in

199
00:09:05,260 --> 00:09:07,260
‫un singolo thread, quindi puoi avere

200
00:09:07,260 --> 00:09:11,230
‫migliaia o milioni di utenti che accedono allo stesso thread contemporaneamente.

201
00:09:11,230 --> 00:09:13,690
‫Ciò rende Node così leggero e scalabile,

202
00:09:13,690 --> 00:09:16,290
‫ma allo stesso tempo presenta il pericolo di

203
00:09:16,290 --> 00:09:17,930
‫bloccare il nostro

204
00:09:17,930 --> 00:09:20,140
‫singolo thread, il che rallenterebbe l'intera

205
00:09:20,140 --> 00:09:25,140
‫app o addirittura si fermerebbe per tutti i tuoi utenti che accedono all'app, giusto?

206
00:09:25,340 --> 00:09:28,110
‫Ora, in altri linguaggi come PHP in esecuzione

207
00:09:28,110 --> 00:09:31,300
‫su un server Apache, in pratica, viene creato un nuovo thread

208
00:09:31,300 --> 00:09:35,200
‫per ogni nuovo utente, che è molto più dispendioso in termini di risorse.

209
00:09:35,200 --> 00:09:37,180
‫Ma d'altra parte, non c'è

210
00:09:37,180 --> 00:09:39,160
‫pericolo di blocco, giusto?

211
00:09:39,160 --> 00:09:41,430
‫Quindi, l'intero modello rende un po'

212
00:09:41,430 --> 00:09:44,340
‫più semplice l'uso di PHP per i principianti, ma

213
00:09:44,340 --> 00:09:46,540
‫ovviamente ha i suoi svantaggi,

214
00:09:46,540 --> 00:09:48,890
‫di cui non parlerò a questo punto.

215
00:09:48,890 --> 00:09:50,690
‫Ad ogni modo, lascia che

216
00:09:50,690 --> 00:09:54,860
‫ti ricordi di nuovo che è tua responsabilità non bloccare il ciclo degli

217
00:09:54,860 --> 00:09:58,150
‫eventi, quindi ecco un paio di linee guida per questo.

218
00:09:58,150 --> 00:10:00,490
‫Prima di tutto, non utilizzare

219
00:10:00,490 --> 00:10:02,850
‫le versioni di sincronizzazione delle funzioni nei

220
00:10:02,850 --> 00:10:06,450
‫moduli fs, crypto o zlib nelle funzioni di callback, ok?

221
00:10:06,450 --> 00:10:09,210
‫Quindi, nel nostro primo progetto, abbiamo effettivamente utilizzato la

222
00:10:09,210 --> 00:10:12,610
‫versione sincrona, ma era nel codice di livello superiore, quindi

223
00:10:12,610 --> 00:10:15,000
‫al di fuori di qualsiasi callback.

224
00:10:15,000 --> 00:10:18,520
‫E poiché quel codice viene eseguito prima ancora che inizi il

225
00:10:18,520 --> 00:10:22,200
‫ciclo degli eventi, beh, non è un problema usare la versione sincrona lì.

226
00:10:22,200 --> 00:10:24,910
‫Inoltre, e questo è probabilmente abbastanza ovvio,

227
00:10:24,910 --> 00:10:28,140
‫non eseguire calcoli molto complessi nel ciclo degli eventi.

228
00:10:28,140 --> 00:10:29,730
‫Quindi, cose come macinare

229
00:10:29,730 --> 00:10:33,890
‫milioni di numeri in loop all'interno di loop o qualcosa del genere.

230
00:10:33,890 --> 00:10:37,550
‫Quindi, fai attenzione con JSON in oggetti molto grandi perché

231
00:10:37,550 --> 00:10:40,480
‫a un certo punto può iniziare a

232
00:10:40,480 --> 00:10:43,440
‫impiegare molto tempo per analizzare o stringere JSON.

233
00:10:43,440 --> 00:10:47,170
‫E infine, non utilizzare espressioni regolari troppo complesse, ad

234
00:10:47,170 --> 00:10:49,840
‫esempio, con più quantificatori nidificati o

235
00:10:49,840 --> 00:10:52,130
‫riferimenti a ritroso, perché di

236
00:10:52,130 --> 00:10:54,810
‫nuovo, possono richiedere più tempo del previsto.

237
00:10:54,810 --> 00:10:56,680
‫Queste sono, ovviamente, solo un paio

238
00:10:56,680 --> 00:10:59,700
‫di linee guida di alto livello, ma ti permetteranno di iniziare

239
00:10:59,700 --> 00:11:00,803
‫sulla strada giusta.

240
00:11:01,650 --> 00:11:03,490
‫Ora, ci sono alcune

241
00:11:03,490 --> 00:11:06,390
‫potenziali soluzioni a questi problemi di blocco, come l'offload

242
00:11:06,390 --> 00:11:09,750
‫manuale nel pool di thread o l'utilizzo di processi figlio,

243
00:11:09,750 --> 00:11:12,070
‫e potremmo parlarne entro la fine del

244
00:11:12,070 --> 00:11:14,370
‫corso o in futuro, ma per

245
00:11:14,370 --> 00:11:17,460
‫ora è importante che capisci e segui questo consiglio

246
00:11:17,460 --> 00:11:20,110
‫di non bloccare davvero il ciclo degli eventi.

247
00:11:20,110 --> 00:11:21,600
‫Va bene.

248
00:11:21,600 --> 00:11:24,520
‫Successivamente, ti darò un piccolo esempio per mostrarti alcune

249
00:11:24,520 --> 00:11:25,990
‫delle cose di

250
00:11:25,990 --> 00:11:27,640
‫cui abbiamo parlato in pratica.