Thread-safe funkce v glibc

[Pavel Kankovsky]

On Mon, 20 Dec 1999, Michal Krause wrote:

> > Mozna uz je to v glibc vychytane, ze se tim neni treba zabyvat a
> > funkce ktere pracuji se statickym bufferem jsou uz v libc obkliceny
> > mutexy... (viz nize)
> 
> Je to mozne. To by ale znamenalo, ze _r ekvivalenty jsou tam jenom pro
> kompatibilitu.

Je rozdil mezi tim, kdy funkce pouziva statickou promennou uvnitr, a tim,
kdy v ni vraci nejaky vysledek. V druhem pripade muze mit v sobe mutexu
milion, ale jak to z ni vyleze ven, tak je to stejne v haji. Z toho duvodu
vznikly *_r funkce.


On Mon, 20 Dec 1999, Ing. Pavel PaJaSoft Janousek wrote:

> 	A nejen to, bohuzel pokud nastane nejaka neocekavana chyba (neosetrena
> vyjimka) v jednom vlakne, jde do kytek cely system (mysleno aplikace),
> coz pri forku znamena zahubu pouze jednoho potomka... - nekdy si rikam,
> zda-li je opravdu ta rezie pri fork a pak nejakem IPC tak velika, ze
> tato implementacni a odladovaci (tedy robustnost) narocnost se
> vyplaci... - asi jak kde a jak na co, pokud je priorita jedine rychlost,
> pak asi jina cesta neni...

Vetsinou ne, ale thready jsou hrozne modni. Mj. taky proto, ze NT
fork() neumi. :)


On Mon, 20 Dec 1999, Michal Krause wrote:

> Nevite nahodou nekdo, co presne vede Apache Foundation k proklamovanemu
> prechodu na vlakna v Apachi 2.0?

Viz vyse.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."