2014-03-14 23:33 GMT+01:00 Balan Victor <balan.vict...@gmail.com>: > Il giorno 14 marzo 2014 18:12, Manlio Perillo <manlio.peri...@gmail.com>ha > scritto: > > >> >> >> 2014-03-13 19:35 GMT+01:00 Balan Victor <balan.vict...@gmail.com>: >> >> Di recente ho letto un po di tornado, e in particolare mi sono soffermato >>> sul modulo tornado.httpserver(Non-blocking HTTP server). Stando a quello >>> che c'è scritto sulla documentazione ufficiale parla di "non-blocking, >>> single-threaded HTTP server" e di risolvere il problemi di tipo C10K. Qua >>> sembra interessante, anche se non ho la minima idea di come funzioni. >>> >> > [...] >> >> L'argomento è complesso. >> > hai da consigliare qualche post/documento/libero che spiega bene > l'argomento?(Italiano/Inglese) ? Su google ne ho trovato alcuni ma non > sono il massimo della chiarezza > > Purtroppo no.
> Nel caso di un server C10K ready ci sono due aspetti principali. >> Il primo riguarda tutto quel codice che esegue una richiesta ed aspetta >> una risposta. >> Il secondo riguarda il paradigma utilizzato per gestire il flusso del >> codice. >> >> Il 97.7% delle librerie disponibili fa qualcosa del tipo: >> >> >>> status = send_request(data) >> >>> resp = recv_response() >> >> Entrambe le funzioni potrebbero metterci molto tempo a completare, ma >> questo codice blocca l'intero thread fino a quando resp non è disponibile. >> >> Quello che fa tornado è di usare quelle che si chiamano coroutine, o >> threading cooperativo. >> In questo caso sia send_request che recv_response bloccano il flusso >> corrente del codice (la coroutine corrente), ma non l'intero thread perchè >> usando le coroutine viene effettuato un salto (simile al goto) che va ad >> eseguire altre funzioni coroutine. >> > e se dentro recv_response ho una chiamata al db perché mi dovrebbe > bloccare? > Se usi la libreria giusta non blocca. Ad esempio la libpq ha un API scritta come si deve (una delle poche, purtroppo, almeno per quello che so) e che permette di fare richieste asincrone. se sono eseguiti in "coruotine" la chiamata al db non dovrebbe andare a > girare in qualche modo in background? > Come detto, devi usare la libreria giusta. PostgreSQL usa libpq che offre un API asincrona, e psycopg usa questa API e le coroutine per fornire una API "semplice". Vedi la documentazione sa: gevent (l'implementazione delle coroutine) sembra risolva tutti i > problemi, ma in realtà tutto quello che fa ha un costo. Non è un caso che > i web server C10K usano la programmazione tramite callback e macchina a > stati; questo perchè è molto più efficiente nella gestione della memoria. > Ogni coroutine è come un thread ed ha bisogno di memoria per lo stack, > oltre poi al costo per il context switch. > E i multiprocessing? Quello che fanno le implementazioni delle coroutine più avanzate, come GHC, Erlang e Go è di reimplementare in user space quello che fa il kernel con i processi, in modo più semplice (perchè il contesto associato ad un green thread è più piccolo rispetto a quello associato ad un processo) ed efficiente, oltre che più "prevedibile". Ciao Manlio
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
