Re: pthread_key_{create,delete} pthread_{g,s}etspecific on NetBSD

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

   Date: Thu, 15 Nov 2012 12:44:05 -0500
   From: christos%zoulas.com@localhost (Christos Zoulas)

   If you read the comments on pthread_tsd.c, we chose a naive and simple
   implementation of those functions, one that chooses not to invalidate
   values of keys in other threads when pthread_key_delete() is called.
   This breaks chromium, which expects pthread_key_delete() to do cleanup
   in all threads. I put a patch on:

       http://www.netbsd.org/~christos/pthread_key.diff

   that changes this. Please comment.

When pulled up to netbsd-6, this patch caused PR 47271.  Quick summary
for those who weren't following it: the patch ~doubles sizeof(struct
__pthread_st), which, on i386 and amd64 and probably elsewhere, made
it span across two pages instead of just one and thereby broke an
assumption made by netbsd-6's libpthread.  Lifting the assumption is
easy, but I'm not sure it's the right thing to do about this.

The reason sizeof(struct __pthread_st) doubled is that we have a fixed
number, 256, of thread-specific data keys, and each pthread has a
preallocated fixed-size array of them.  Formerly each key required one
pointer in each thread; christos's patch adds two more.

This strikes me as suboptimal and worthy of discussion, although I
don't have any specific performance problems to cite at the moment.
Opinions?