[python] select vs threads

[Zdenek Pavlas]

Radim Kolar wrote:

> Zajimalo by mne jak nejlepe / t.j. s nejmensi namahou/ nabastlit jeho serverovou
> cast.  Zda je lepsi pouzit thready per client nebo select(). Pokud jde o
> efektivitu kodu select bude asi rychlejsi, protoze kernel nebude muset delat
> zbytecne context switche.

Mam dobre zkusenosti s pouzivanim threadoveho modelu.
Rezie na switchovani threadu je zcela minimalni, na Linuxu
zadne problemy. Vede to na maly, prehledny, 
dobre udrzovatelny kod.

Je akorat dobre pro provozni nasazeni kazdy dulezitejsi 
thread (minimalne kazdou accept() smycku) obalit jednim 
try: except:, vyjimky logovat, a smycku restartovat.

Problemy jsou spis v tomto:

- udelat spravne zamykani muze byt problem, Python navic
  umi jen exklusivni locky, vsechno ostatni je nad tim
  dost nesikovne a pomalu emulovano (Rlock, Condition).
  Je zahodno .release () davat pokudmozno do finally: :)

- signaly jsou vsude mimo Linux velky problem. Moc tomu 
  nerozumim, ale POSIXove thready jsou navrzeny nejak 
  idiotsky, takze vetsina implementaci potrebuje pri prvnim 
  vytvorenem threadu spustit jeste jeden "servisni" thread,
  a v OSech kde vsechny thready maji stejny PID je nemozne
  urcit ktery thread signal obdrzi, a chovani toho servisniho
  threadu nejde menit. Aplikace ktere na Linuxu nebo Solarisu
  bezi OK mi padaji na FreeBSD po SIGHUP kvuli reloadu 
  konfigurace, a neprisel jsem na to jestli/jak
  to vyresit. To ze threading +signaly = trouble je tusim
  i nekde v dokumentaci Pythonu.

> Neni lepsi pouzit twisted framework?

Mi to prislo jako mamut, psany nejakym OO maniakem,
ktery na kdejakou blbost, kterou normalni clovek nekam
prilepi jako kus kodu, pise samostatnou tridu, na uplne
jinem miste vytvari instanci, a nekde zase uplne jinde
to poslepuje dohromady, v dusledku cehoz se v tom vubec
neda vyznat. Pouzit jsem to radeji ani nezkousel, ale
mozna ze jini maji jine zkusenosti.

-- 
Zdenek Pavlas