Thread-safe funkce v glibc

[Lubos Lunak]

Michal Krause wrote:
> 
> On 12/20/99 13:39, Lubos Lunak wrote:
> 
[snip]
> 
> 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).

 To nic. Kdyz se info prohlizi v mc jako obycejny textovy file, je to uz
skoro jako manpage :)).

> 
> > 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" :(

 No, mozna jsem to trochu prehnal. Sice to zaboha nemuzu najit primo v
dokumentaci glibc2, ale uz jsem parkrat videl tvrzeni, ze glibc2 je 100%
thread-safe ( cimz je zrejme mineno, ze funkce ma bud svoji _r variantu,
nebo je reentrantni, a tam kde to je potreba, tak je i thread-safe ).
Snad to tak i je.

> 
[snip]
> > 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 ...

 Nemyslel jsem zadne masivni predelavani, jen ze kdyz bude potreba volat
gethostbyname() vicekrat naraz ( jako ze to vetsinou neni treba ), tak
ze je udajne lepsi udelat nekolikrat fork()+exec() maleho programku,
ktery jen zavola gethostbyname() a vrati vysledek.

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

 Paklize glibc2 je opravdu 100% ok, tak to neni treba. Navic, jeste
snazsi co se implementace tyce by mozna bylo prejit na cooperativni
multithreading s jeho vyhodami a nevyhodami ( at uz
http://www.gnu.org/software/pth nebo ho udelat z preemptivniho pomoci
jednoho velkeho mutexu v nejakem my_yield()). To uz ale zalezi od
programu.

> 
> > A nebo si slabsi povahy z toho muzou hodit masli. Thready dneska holt
> > jeste nejsou zadna sranda.
> 
> Koukam...
> 
> S pozdravem
> --
> Michal Krause                                                      /\

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