> Nicola Larosa ha scritto: >> Ovviamente l'ideale, usando Twisted, sarebbe di non usare per niente i >> thread, o almeno limitarli all'indispensabile, come l'accesso al >> database. In quel caso non si può passare per WSGI, che non supporta >> gli eventi asincroni, ma bisogna scrivere un apposito handler di >> Django usando oculatamente i Deferred di Twisted (magari completando >> quello già iniziato che mi ritrovo casualmente sul disco ;-D ).
Manlio Perillo wrote: > Ti stai riferendo a: http://code.djangoproject.com/ticket/2904 ? No, non l'avevo visto, grazie per il riferimento. Mi riferisco a un abbozzo di handler scritto da un mio amico (hi, pr0gg3d!) col mio aiuto. Il ticket da te indicato cerca di mantenere la compatibilità con WSGI: il nostro cerca di integrare direttamente Twisted e Django. >> A quel punto l'intera architettura è asincrona, tranne le parti dove >> si continuano a usare i thread, e bisogna seguire ovunque il principio >> guida di Twisted di non scrivere codice bloccante. > La vedo ardua dato che puoi accedere a codice bloccante in modo non > controllabile quando usi un database. > > Ad esempio, a quanto ho capito, viene usato sempre il lazy loading, > quindi una chiamata a obj.xxx può causare una query. Questo è infatti lo scoglio principale. > Una soluzione potrebbe essere quella di eseguire l'intera view in un > thread (e transazione) separati. Questo approccio è meno invasivo, non devi propagare tanti Deferred in giro, però non è molto diverso dall'approccio attuale via WSGI. > E' quello che volevo fare con Nevow, ma SQLAlchemy si è rivelato molto > flessibile. Quello che ho fatto è stato semplicemente scrivere dei > decoratori: > > @engine.transact def getXXXList(conn, ...): ... > > @engine.transactSession def getYYYList(conn, sess, ...): ... Abbiamo fatto qualcosa di molto simile, con SQLAlchemy e Twisted, in un progetto a cui sto lavorando. > Non ho idea se lo stesso si possa fare agevolmente con Django (e devo > dire che non ho molta voglia di indagare). L'approccio "light" continua a essere sostanzialmente multithreaded, cosa già fornita dall'integrazione WSGI. L'approccio invasivo converte una maggior parte dell'architettura al modello di Twisted, ma da un lato non è facile da scrivere, e dall'altro sconvolge le API di Django e lo rende incompatibile con i siti sviluppati per la versione ufficiale. -- Nicola Larosa - http://www.tekNico.net/ I have been working on a design doc for restricted execution of Python as part of my dissertation for getting Python into Firefox to replace JavaScript on the web. -- Brett Cannon, June 2006 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
