h.b.furuseth@usit.uio.no writes:

Oh, and make max_pending 0 or greater, since negative numbers confuse pool_query().

I'll do that one, since it fixes a bug and removes no functionality. (And I forgot a few others, e.g. swapkey() function I mentioned earlier, but guess I'd prefer to stick to single-file changes for now.)

...

OK, suppose we use a pthread thread-specific key here. What are you proposing for the unique value?

An unsigned long counter, maintained by libldap_r. If the thread-local variable is zero (thus uninitialized), increment the counter and grab its value.

I forgot keys must be pointers. So ldap_pvt_thread_unique_id() would malloc it if not already set, and fill in with the incremented pointers. For pool threads that'd not be necessary: The thread-local could hold the pointer to the thread context, and the thread could have unique ID (thread_context - thread_keys + 1). The "+1" in case others think thread ID 0 means no thread, like tpool thought recently.

The comp.programming.threads question took off in an unexpected direction, so I'm not holding my breath about answers to DCE threads and the like.

OS/390 threads - a quick google does seem to indicate that OS/400 threads (and thus presumably OS/390) resemble DCE threads. At least they have a pthread_getunique_np() function, and possibly "field1-3".