Howard Chu writes: It's called from pool_wrapper(). pool_wrapper() could go active so there can be no pause while that context_reset() call is running. (need to check out how it should work...) Note that I did say "least unlikely" rather than "most likely": It's not that I expect to encounter it, more that I'd prefer not to be surprised in the form of a slapd malfuntion. So in that respect, my preference (not for RE23) is to cast to an integer for the hash, and also to add pthread_<set/get>specific() so thread_keys[] and its hash will only be a fallback solution. No. Valid compiler, valid code. Therefore valgrind is silent about copying uninitialized values, it only complains when you use them for something - like write() or arithmetic. So a valgrind complaint about an uninitialized _value_ isn't necessary at the point the uninitialized _variable_ is read. E.g. this complains in printf(), not in foo(): int foo() { struct { char c; /*maybe padding here*/ int j; } s; s.c = 1; s.j = 2; return ((unsigned char *)&s)[1]; /* maybe padding byte */ } int main() { printf("%d\n", foo()); } Right, at this point I answered how it _can_ happen, not why I expect to encounter it. I could see the demands of hardware design cause strange memory models to proliferate again, but I'm not holding my breath. I'd be a bit less surprised to encounter integers with padding bits again, but not for a simple ID type, and hashing an integer instead of its bytes would fix it anyway. I'm not sure how to determine _which_ multiple of 1MB - start two threads and compare their stack addresses, maybe? In any case, I agree it sounds rather more machine-dependent than the current code. -- Regards, Hallvard