Subject: Re: nsswitch.conf and irs.conf
To: Noriyuki Soda <email@example.com>
From: None <firstname.lastname@example.org>
Date: 01/21/2003 14:26:37
>>> 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?
>- 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.