Thread-safe funkce v glibc

[Martin Kavalec]

20 Dec 1999 14:52:00 +0100 v cz.comp.linux Michal Krause napsal:
> 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?
> > 

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

Taky jsem to hledal a nenasel. Ale v infu ke starsi libc tusim
takovy seznam byl.
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)

> Na info jsem docista zapomnel (je s podivem, ze za tu dlouhou dobu, co
> pouzivam Linux jsem si na nej oproti manu nejak nezvyknul).
 
taky mi 'man neco' prijde rychlejsi nez 'info neco' a pak se
dohrabavat kyzene informace. Ale info k libc je pekne napsane a
dost veci jsem se z toho naucil. A ma i rejstrik, takze kdyz
stisknu 'i' je to uz skoro jako man :-)

[snip]

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

info '(libc)Host Names'

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

Kdysi jsem se taky snazil napsat jeden programek reentrantni 
a pri pouzivani gdb jsem ziskal dojem, ze pri kompilovani 
s _REENTRANT jsou ty mutexy uz primo v libc -- pokud nejaky
thread resolvoval a jiny chtel taky, pak ten druhy visel na
nejakem mutexu, ktery jsem tam urcite nedaval.  

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

Taky jsem to nakonec predelal na samostatne procesy komunikujici
pres PF_UNIX socket :-| (ale bylo to proto, ze jsem tam mel jine
bugy, ktere se mi v tech threadech spatne hledaly; navic jsem se
snazil nezavrit si cestu zpatky ke threadum, kdyby to nekdy bylo
potreba)

Zdravi
martin