Re: (ITS#4943) tpool.c pause vs. finish

[h.b.furuseth@usit.uio.no]

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".

-- 
Regards,
Hallvard