Davide Alberani ha scritto:
...
Su localhost, macchina lentuccia ed indaffarata, col tuo codice ho
comportamenti buffi aumentando il numero di thread, ricevendo
una eccezione (python 2.4):
...
Uhmmmm ... molto strano.
a me è capitato solo lanciandolo in debug mode da dentro l'IDE.
... ma questo me lo aspetto: non ho fiducia nel "debug mode"
quando si parla di m-threading.
Visto che in passato ho sofferto molto a causa del m-threading e che
ho un po' di tempo libero, ho deciso di "togliermi qualche sassolino
dalla scarpa"
Avviso ai naviganti:
questa è una sclerata su codice masochistico.
procedete a Vs. rischio e pericolo. You were warned :-)
Ho provato lo stesso codice di prima con 100.000 thread su diversi O.S.
tutti con Python 2.4.3
- sotto Ubuntu 6.06 su un P3 500Mhz con 512 Mb ram
ci mette 1 minuto, CPU fissa al 100%, occupa circa 100 Mb
0 problemi
- sotto Winzoz XP su un P4 3 Ghz con 1 Gb ram
ci mette circa 3 minuti, CPU al 100%, occupa circa 100 Mb
Mia "sensazione" dovuta all'osservazione delle "risorse di sistema":
mi pare che utilizzi pochi thread "veri" e sequenzializzi.
Questa "sensazione" è suffragata da:
1) i tempi: un PC molto + veloce ci mette 3 volte di +
2) un sguardo all'ordine dei pacchetti UDP arrivati sul server.
Sono tutti "numericamente vicini", a occhio lo scarto massimo è delle decine,
con linux c'erano casi con discordanze di diverse centinaia
Ok, a parità di logica, linux è molto migliore di winzoz su tutto quello che
riguarda le socket (e non solo), ma sui thread il prodotto di seattle dovrebbe
cavarsela egregiamente (almeno questa è la mia esperienza).
E poi ... 3 volte di + e sequenziale? a tutto c'è un limite.
Uhmmmmm ... qualcosa tocca.
- con Mac OSX 10.4 su un Mac Book Intel Core Duo 2Ghz, 2 Gb ram
ci mette più di 50 minuti (!), CPU al 4%
i messaggi arrivano perfettamente ordinati
... ma stiamo scherzando???
Bloccando l'esecuzione in qualsiasi momento si scopre l'arcano
"""
File "clientUDP.py", line 23, in ?
for c in clienti: c.start()
File
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py",
line 418, in start
_sleep(0.000001) # 1 usec, to let the thread run (Solaris hack)
"""
Le librerie pitoniche del Mac introducono uno sleep sull'avvio del thread!
Quindi, mentre il thread X "parte" il sistema si fa una penichella,
(e di _almeno_ un microsecondo, la sleep pitonica non è precisissima),
così che, al risveglio, quando lancia il thread X+1, il thread X è già storia.
Questo giustifica alcune "cose molto strane" che vedevo sul mac.
Non ho parole ... ho solo voglia di spaccare in due una mela!
Maurizio Lemmo - Tannoiser ha scritto:
...
> Non e` che python succhia?
si, per fare cose del genere posso essere d'accordo.
Comunque,
nella "vita reale" non mi verrebbe mai in mente di aprire tanti thread con
il serpide sotto qualsiasi sistema operativo.
Anche perché le funzioni "select" e "poll" (solo *nix) le hanno fatte apposta.
Inoltre tieni conto della "perversione intrinseca" al codice che ho mandato:
apre N thread all'unico scopo di utilizzare (sincronizzarsi) su un'unica
risorsa, detenuta dal s.o. e che, per sua natura, è sequenziale.
Se qualcuno scrive un codice del genere in un programma vero deve essere
crocifisso in sala mensa, a monito per le genti.
... ma in un raffinato cenacolo di masochisti, direi che ha un suo perché
:-D
TaZ
|