[Python] 10 myths

[Roberto De Ioris]

> Nicola Larosa <nico a teknico.net>:
>
>> Impatta la scalabilità. Usare un thread per ogni operazione
>> concorrente significa esser limitati a qualche migliaio di esecuzioni
>> contemporanee, con alti consumi di memoria.
>>
>> Per arrivare a milioni di connessioni contemporanee bisogna usare
>> approcci
>> più come gli eventi asincroni, o i "processi" di Erlang, o appunto le
>> goroutine del runtime di Go.
>>
>
> Vista la vostra esperienza,
> giusto per paragone, visto che conosco bene java,
>
> Per scalare milioni di connessioni si usa un selector thread che gestisce
> tutte le connessioni chiamate native I/O e attiva un thread da un pool per
> gestire la richiesta una volta che che è arrivata. Questo permette di
> avere
> migliaia di connessoni per JVM.
>
> Tenendo conto che l'I/O è estremamente più lento di gestire una richiesta,
> un solo selector thread gestisce facilmente tante socket ciclando su
> ognuona di esse in modo sequenziale.
>
> E i threads che gestisono le richieste sono rapidi in quanto non non sono
> appesi ad aspettare bytes dalle socket.
>
> c'è una libreria python che si avvicina a questo modello?
>


Sei sicuro che funzioni cosi' ? Proprio il mese scorso ho "smembrato" uno
stack j2ee (jboss, coucho resin ecc. ecc.) e da quello che ho visto il
thread selector si limita a chiamare l'accept() e tenere il file
descriptor "in coda" nell'attesa che ci sia un thread in attesa (tra
quelli fissi del pool).

Quindi hai solo aumentato la mole di richieste che puoi mettere in coda,
non quante ne puoi gestire in concorrenza. (il che mi sembra un
bell'approccio enterprise per vendere a qualche dirigente bambacione)


Quello che descrivi te mi sembra parecchio rocambolesco (continuo context
switch tra thread dedicati all'i/o e tread puramente cpu-centrici), ma se
e' davvero cosi', tanto di cappello :)



-- 
Roberto De Ioris
http://unbit.com