[Date Prev][Date Next]
Re: (ITS#4943) tpool.c pause vs. finish
>> I wonder if we've been waiting for each other... Anyway, I've committed
>> some pending fixes now that HEAD passes all tests for me. I've some
>> more cleanup, but if we are close to a freeze I don't know if that means
>> I should rush it in or wait until afterwards.
> Cleanup as in tidying the code, or as in fixing functionality?
One cleanup (move thread start before queuing task in pool_submit(),
one mini functionality: Make thread counts int instead of long, since
pool_query() wants that. Oh, and make max_pending 0 or greater, since
negative numbers confuse pool_query().
>> Another time when tls.c code loses information is if pointers are wider
>> than long, which does happen. (Don't know how it is nowadays, but I
>> remember plenty of postings about it some years ago.)
> Probably the OpenSSL API should have used a void * here. Too bad.
Yup. I've seen mention it is coming in future version.
> 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
>>>>> It's really
>>>>> not hard. If we were to disallow increasing the number of threads at
>>>>> runtime, we could simply allocate a block of thread stacks all at once,
>>>>> which would then allow our thread IDs to be simple integers from 0-N.
>> IIRC disallowing that would fix some other tpool problem too, but I
>> don't remember what.
> I'm not really keen on that since I like having the ability to both increase
> and decrease the setting dynamically.
Me too, the only pro is it makes implementation simpler.
>> Which led me to notice that the setstacksize call now _decreases_ the
>> stack size on some hosts. I don't suppose that was intentional, so I
>> guess it should be
>> size_t cursize;
>> if( pthread_attr_getstacksize( &attr, &cursize )
>> || cursize < LDAP_PVT_THREAD_STACK_SIZE )
>> pthread_attr_setstacksize( &attr, LDAP_PVT_THREAD_STACK_SIZE );
>> in thr_posix and I don't know what in other thr_* files. A RE24 change
>> I guess, since reduces the max number of threads before slapd gets into
> I don't consider this a bug. If someone wants a larger thread stack
> they can recompile to get it. Or perhaps we should make it a tunable
> variable and add a config keyword for it.