[Date Prev][Date Next]
Re: (ITS#4943) tpool.c pause vs. finish
> 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
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".