Thread-safe funkce v glibc

[Michal Krause]

On 12/20/99 13:39, Lubos Lunak wrote:

> > 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.

Diky za vycerpavajici info, je fakt, ze v podstate hledam reentrantni
funkce, protoze thready operuji nad svymi vlastnimi daty. Spatne jsem se
vyjadril.

>  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'

Na info jsem docista zapomnel (je s podivem, ze za tu dlouhou dobu, co
pouzivam Linux jsem si na nej oproti manu nejak nezvyknul).

> 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.

Hm, takze to vypada na "use the source" :(

> > 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()).

Brr. Preci nebudu kvuli gethostbyaddr predelavat cely program? To snad
radeji udelam jeden specialni thread pro resolvovani nebo ...

>  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.

... opravdu pouziju ten mutex. Vykonostne to bude asi totez a na
implementaci snazsi.

> A nebo si slabsi povahy z toho muzou hodit masli. Thready dneska holt
> jeste nejsou zadna sranda.

Koukam...

S pozdravem
--
Michal Krause                                                      /\
ICQ: 7665279            Informace (nejenom) ze sveta Linuxu     /\/  \
email: mike na navrcholu.cz ______ http://www.root.cz/ ______ NAVRCHOLU.cz

Co napsat do signatury, aby to nikoho nepohorsilo? Snad jedine nejakou
obecne znamou pravdu. Doufam, ze vsichni vite, ze tucnak je bylozrava ryba.