Thread-safe funkce v glibc

[Lubos Lunak]

Michal Krause wrote:
> 
> Zdravim,
> 
> mohl by me nekdo nasmerovat nekam, kde si prectu, ktere glibc (2.1)
> funkce jsou thread-safe? Nebo jsou to vsechny, pokud je definovan symbol
> _REENTRANT?

 No, zakladem je zkusit 'info libc' nebo manpages, i kdyz tolik se tam
toho zase nenajde :(. Pokud ted pomineme fakt, ze pod 'thread-safe' si
lze predstavit nekolik ruznych veci, tak obecne by glibc2 mela byt
kompletne thread-safe. Obecne by melo platit, ze kdyz funkce nevraci ptr
na static nebo pri dalsim vyvolani nepouziva data ulozena pri predchozim
volani do nejake static, tak muze byt soucasne vyvolana vicekrat, pokud
ta ruzna volani operuji nad ruznymi daty ( tj. vetsina funkci vlastne je
jen reentratni, ale uz ne thread-safe - nakonec, volat vicekrat strpcy()
do stejneho retezce vicekrat je stejne blbost ). Nektere dalsi funkce (
napr. fwrite()) mohou byt vyvolany vicekrat i nad stejnymi daty ( napr.
stejny filedesc. ), ty pak jsou skutecne thread-safe.
 Jenze porad zustava ten problem, ktere to jsou, ze ? Hledani v manpages
je zrejme ztrata casu ( grep tam toho fakt moc nenasel ). V 'info libc'
uz neco je, i kdyz vetsinou je tam jen konstatovani, ze funkce je
cancellation point. Takze pokud nahodou nekdo nevi neco lepsiho, tak
stejne nezbyde nez si pomoct sam. Logicky, pokud ma funkce smysl ji
volat vicekrat nad stejnymi daty naraz, tak nejspis bude thread-safe,
jinak bude reentrant, no a pokud provadi neco se static, tak neni ani
to. Pri hledani primo ve zdrojacich te funkce, pokud vola nekde
pthread_xxx(), tak bude thread-safe, pokud tam nikde neni static
promenna, tak je reentrant. Jinak pri hledani mohou take pomoct manpages
ze Solarisu, ty jsou co se threadu tyce trochu vice ukecane, snad by to
mohlo docela glibc odpovidat.

> 
> Jak je to s ekvivalenty s _r? Napriklad gethostbyaddr_r rve, ze ma
> nespravny pocet parametru (kdyz jsem pouzil to same, co u normalniho
> gethostbyaddr), ale man se k temhle funkcim nezna. Kde tedy zjistim, jak
> se ma spravne volat?

 Jinak to _REENTRANT jen znamena, ze se spravne udela per-thread errno
promenna a take reentrantni verze funkci, ktere jinak pouzivaji static.
Napr. gethostbyname() vraci tusim static, takze neni ani reentrant. _r
verze funkci obycejne berou navic parametr(y), ktere urcuji, kam se maji
ulozit ta data, ktera by jinak sla do static. ( Kdyz uz jsme u
gethostbyname_r(), udajne je to pekne nepovedena bestie a je lepsi na to
udelat treba fork() a volat normalni gethostbyname()). Znovu, Solaris ma
i tyhle funkce tusim dokumentovane, i kdyz si tedy nejsem tak moc jisty.

> 
> Diky
> --
> Michal Krause                                                      /\

 Jo, a jeste, pokud ta funkce bude volana jen v jednom threadu ( jedno v
kterem ) a jsou spravne veci kolem errno a tak, tak samozrejme pak by
mela byt v poradku kazda takhle volana funkce. Nebo se ta volani daji
hlidat mutexem.
A nebo si slabsi povahy z toho muzou hodit masli. Thready dneska holt
jeste nejsou zadna sranda.

 Lubos Lunak
 l.lunak na email.cz http://dforce.sh.cvut.cz/~seli     ---KDE Now!---