Rychlost paralelniho resolvovani (long)

[Pavel Kankovsky]

On Fri, 12 Jan 2001, Michal Krause wrote:

> #3  0x400437ba in __pthread_mutex_lock (mutex=0x4038fe04) at mutex.c:84
> #4  0x40389d20 in __res_send (buf=0xbebfeb8c "3+\001", buflen=45, 
>     ans=0xbebff3c4 "dóż°ä˙\027@Ěá\027@@ţżž$˙żž13\0031", anssiz=1024) at res_send.c:321
> #5  0x4038944e in res_query (name=0xbebfefc0 "42.113.113.195.in-addr.arpa", class=1, type=12, 
>     answer=0xbebff3c4 "dóż°ä˙\027@Ěá\027@@ţżž$˙żž13\0031", anslen=1024) at res_query.c:134

Rekl bych, ze zpomaleni nebude takova zahada, kdyz resolver uvnitr provadi
nejake hratky s mutexy -- zadna paralelizace se neprovadi a navic je to 
jeste pomalejsi o sychronizacni rezii. I kdyz je tedy ponekud divne, ze by
ta rezie mutexu byla tak velika.

> (mimochodem, nevi nekdo, proc pri attachnuti threadu gdb nelze prohlizet
> skoro zadne promenne? - viz argumenty funkci).

Ja bych rekl, ze argumenty jsou dobre (viz name u res_query()).
To, ze je ve vecech jako buf a ans(wer) binarni smeti, je celkem
pochopitelne, kdyz se tam strkaji DNS zpravy.

P.S. Jinak bacha na strncpy(). Nezarucuje, ze kopie bude mit na
konci '\0', coz muze byt neprijemne, pokud ji pak pouzivame jako string.

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