[ntp:questions] NEED_PTHREAD_WARMUP section in ntpd/ntpd.c

juergen perlinger juergen.perlinger at t-online.de
Thu Feb 23 19:07:39 UTC 2017


On 02/22/2017 06:06 PM, Sundeep Lal wrote:
> Starting with ntp-4.2.8p4 a new section was added to ntp-4.2.8p4/ntpd/ntpd.c at line 273:
> 
> #ifdef NEED_PTHREAD_WARMUP
> static void*
> my_pthread_warmup_worker(void *thread_args)
> {
> ..
> ..
> }
> 
> ..
> ..
> #endif
> 
> The my_pthread_warmup_worker() thread function does not make use of pthread_setcancelstate()
> and pthread_setcanceltype(), and in some uclibc based systems this
causes the pthread_cancel()
> call on line 299 to take no effect. Then, in line 300 when pthread_join() is invoked, ntpd forever
> remains in my_pthread_warmup_worker() thread. For such uclibc systems,
we should add the following
> lines to my_pthread_warmup_worker():
> 
> static void*
> my_pthread_warmup_worker(void *thread_args)
> {
>   pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
>   pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
>   (void)thread_args;
>   ..
>   ..
> }
> 
> My question is: has the above already been reported in any bug? I could not find any pull request for the same.

This has several aspects:

http://pubs.opengroup.org/onlinepubs/9699919799/ clearly states

"""
The cancelability state and type of any newly created threads, including
the thread in which main() was first invoked, shall be
PTHREAD_CANCEL_ENABLE and PTHREAD_CANCEL_DEFERRED respectively.
"""

So uClibc is definitely not conforming to the POSIX standard. Things
like this happen, but that might explain why nobody has filed a bug
against this yet.

The other aspect is that asynchronous cancellation is a *BAAAAAD* idea
in 99.9995% of all cases. I'm not adverse to enabling the cancellation,
but using asynchronous cancellation? Is there compelling reason to do so?

If it is really needed for some/all versions of the lib this could be
packed in an '#ifdef' that enables this only for the systems that need it.

But according to the standard, 'sleep()' is a thread cancellation point.
If it is not so in uClibc, we might sleep for a much shorter interval
and use 'pthread_testcancel()'. This would still be portable and cause
little problems, as far as I can tell.

So can you perhaps come up with a solution that does not use
asynchronous cancellation, or a preprocessor conditional that does limit
the effect to uClibc?

Maybe even better, do you *need* the warm-up? It is needed to get parts
of the GCC runtime into the executable *before* the resource limits and
page locks are engaged. This is an issue with gcc/glibc, mostly. If you
don't need that, maybe we could make the preprocessor conditional more
specific / less general?

Some more input on this would be warmly welcomed. Asynchronous
cancellation is generally not :)

Cheers,
	Pearly



More information about the questions mailing list