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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
