>>>>> On Fri, 06 Jun 2003 19:31:31 +0900, itojun@iijlab.net said:

> 	as we start providing thread-safe library implementations, we
> 	will need to re-do what ISC did with net_data.

That's not true. Actually I think we shouldn't use thread-specific
data (i.e. net_data) like what the IRS implementation does.

I don't say we should completely avoid thread-specific data.
For example, `errno' is a thread-specific data and it must be.
But we should avoid thread-specifc data, if possible.
Here are the reasons:

- de facto standard behavior cannot be achieved.

  As I wrote already, gethostent_r() behavior in the IRS implementation
  is different from de facto standard behavior like what Solaris and
  glibc does.
  In Solaris and glibc, the current position of gethostent_r() within
  an enumeration is a process-wide property which is shared by all
  threads.
  But in the IRS library, the current position is a thread-specific
  property, and it is not shared by other threads, because the
  position is stored in thread-specific data.

  We should avoid thread-specific data for things like this.

- It's waste.

  If some standards require thread-specific data, we must use it
  (like `errno'). But if standard doesn't require thread-specific
  data, we should avoid it. Because overusing thread-specific data
  wastes memory and other resources.
  For example, not only gethostbyname_r() and gethostent_r(), but also
  gethostname() and gethostent() *are* reentrant in the IRS
  implementation. This is just waste.

The reason I don't prefer the IRS implemetation is that the
implemetation is blindly storing everything in thread-specific data.
This is not right.
--
soda