[python] sockety - problem s HTTP spojenim

[superman]

> No, mohl bych poprosit o referenci na nejaky zdroj, ktery tvrdi, ze od
> zacatku provadeni vyrazu "buffer += foo" az po jeho dokonceni se
> nedostane ke slovu jiny thread?

Ne, tato operace rozhodně atomická není a ani být nemůže. To, že tam 
jsou immutable stringy situace dost zlepšuje, nicméně o atomičnosti 
operace nemůže být ani řeči.

> Vzhledem k tomu, ze se celkem bezne [1] tvrdi, ze += 1 na int *neni*
> atomicke, tak soudim, ze append na (immutable) stringy rovnez nebude.

Pokud je vykonávána operace (int) += 1, pak tato instrukce v rámci 
strojového kódu atomická být samozřejmě může. Přímo assembler většiny 
procesorů umožňuje tuto operaci vykonat atomicky.

Druhá otázka je, zda a jak tuto instrukci vykonává Python, a zda možnost 
atomičnosti této operaci podporované dokonce přímo na úrovni procesoru 
využije, nebo hodí do kopru.

Jinak atomickou incrementaci int podporují i operační systémy (například 
na Windows funkce InterlockedIncrement()), nebo základní knihovny mnoha 
překladačů (třeba funkce __atomic_inc() v gcc). Takže zde jen záleží na 
interpreteru Pythonu, zda využije této možnosti.

>>3) vzhledem k pythonímu GIL je vše (mnohdy až příliš) thread-safe a pokud
>>   nepoužíváte nějaké neobvyklé C extenze, nemusíte zamykat skoro nic
> 
> Silne nesouhlasim, viz znovu [1]. Dalsi vygoogleny odkaz je thread [2].

Ač jsem nečetl nic a dokonce se přiznávám, že vůbec netuším, co je to 
GIL - jako člověk, který napsat fůru multithreadových aplikací toto 
sebevědomí mi říká, že autor o thread safe programování moc neví.

Dokonalé zajištění thread safe je VELMI DRAHÁ záležitost, pro kterou 
musíte obětovat velmi mnoho rychlosti a efektivity programu, pokud jí 
chcete zajistit naprosto obecně. Z těchto důvodů dokonalé thread safe 
věci NEEXISTUJÍ (vynechám-li triviální věci a triviální problémy). Vždy 
je potřeba udělat ústupky, má-li to vůbec být použitelné. V opačném 
případě je to nepoužitelné a velmi náchylné k deadlockům.

Miloslav Ponkrác