Forum libero

Scritto da: ::1
> Scritto da: Wakko Warner
> > Scritto da: avvelentani
> > > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> > >
> > > Le chiamate bloccanti erano ancora piu` semplici.
> >
> > Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
> >
> > Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> > Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
> >
> > Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
> >
> > Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
> >
> > Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
> >
> > Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
> >
> > Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
>
> A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.

E perché ti importa? È una cosa di cui si occupa il compilatore, non devi occupartene tu. Ti poni tutti questi problemi anche circa come il compilatore compila il tuo codice in assembly? Non credo... dai per scontato che lo faccia correttamente... non vai certo a verificare se ha azzerato la tua variabile con un assegnamento o uno xor con se stesso.

Metti ora sul piatto i vantaggi che async/await ti danno, in primis la facilità di ragionare sul codice, di capirlo, mantenerlo, ecc.

IMO più è la macchina ad occuparsi dei dettagli e più sono sicuro che il codice faccia esattamente quello che voglio faccia, meno codice scrivo e più sono sicuro di non aver introdotto bug, più facile il codice è da leggere e meno mi fa diventare matto e fa perdere tempo. Al cliente non glie ne frega nulla di come hai raggiunto il risultato, a lui interessa che il risultato sia quello che si aspettava, che abbia meno bug possibili ed ottenerlo nel più breve tempo possibile.

Se io e te facciamo lo stesso software ma tu impieghi 1 mese e 3000 euro in più di me per farglielo, da chi credi lo comprerà? Alla fine a te sviluppatore interessa guadagnare con meno sforzo possibile (che è poi quello che interessa tutti) e il tuo cliente avere quello che ha chiesto il prima possibile pagandolo il meno possibile.

Non so te, ma io do un alto valore al mio tempo e preferisco avere più tempo libero possibile. Impiegare il mio tempo decifrando quello che succede in mille mila callback annidiate non è il modo in cui preferisco passare il mio tempo né tantomeno mi piace stare a spaccarmi la testa su problemi che si possono evitare interamente.

> Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).

Non è gratuito, ma non ti importa, è un lavoro che fa il tuo strumento di sviluppo in fase di debug e ti rende più semplice la vita. Perché lamentarsene?

> Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).

Hai mai provato a sviluppare qualcosa per android? Magari con phonegap dove ogni 3 righe hai una callback? Lì semplicemente non puoi evitarle perché è l'ambiente stesso che non ti offre alternative sincrone. Io l'ho fatto, ed è un'esperienza che preferirei non ripetere. Con i Future le cose un po'si semplificano, ma sono comunque lontane anni luce dalla semplicità dell'await/async.

Scritto da: ::1
> Scritto da: Wakko Warner
> > Scritto da: avvelentani
> > > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> > >
> > > Le chiamate bloccanti erano ancora piu` semplici.
> >
> > Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
> >
> > Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> > Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
> >
> > Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
> >
> > Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
> >
> > Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
> >
> > Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
> >
> > Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
>
> A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.
> Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).
> Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).

Non capisco una mazza di questo thread, ma sono contento che ci sia.