>>> In this file, gethostbyname_r(3) calls gethostbyname(3) internally.
>>> In other words, what the IRS did is to make gethostbyname(3) MT safe
>>> to implement gethostbyname_r(3). :-O
>>> This is what I think wasteful.
>
>> 	what is wrong with that?
>
>Because: 
>
>- Using thread specific data has certain overhead on both
>  time and space.

	it's a tradeoff against code duplication and extra maintenance headache.

>- Using thread specific data makes code maintainability worse.
>  (You already saw I mistread it.)
>  It is nearly always better to pass per-thread data explicitly
>  in a function argument, rather than implicitly by using a
>  thread specific data, for code maintenance POV.
>  There are cases that one has to use thread specific data,
>  when one cannot change an intermediate function interface.
>  But in this IRS case, the thread specific data is not really
>  needed, because the IRS library can choose any function interface
>  in its internal implemetataion.

	i don't think you have read through IRS library, have you?  IMHO,
	you have no right to comment on this topic.  it always
	pass around pointer to struct net_data, which holds the data necessary
	for the thread.  it does not really rely upon thread specific data
	pthreads provides (you can compile BIND8 resolver without pthreads
	support - see #ifdef DO_PTHREADS).

>- It may make problems about reusability of our code.
>  If we make gethostbyname(3) thread safe, some of our code
>  may depend on the fact (by intentionally or accidentally).
>  Because such thread safe assumption of gethostbyname(3) isn't true
>  on other platforms, the code which depends on the assumption becomes
>  non portable to other platfroms.
>  So, if we make gethostbyname(3) thread safe, reusability
>  of our code may become worse.

	this is totally nonsense.  feel free to tell this to BIND8 developers.

itojun