Re: [PATCH][BZ #13613] Allow a single-threaded process to cancel itself

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Thu, May 10, 2012 at 11:34 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, May 10, 2012 at 08:22:55AM -0700, Richard Henderson wrote:
>> ... which to me means this change is just busy work. ?I think the
>> comment in pthread_cancel ought to be sufficient.
>
> Yeah, comment should be enough, the proposed changes are terribly ugly.
>
> multiple_threads btw doesn't mean that there is currently more than one
> thread running, it is sticky, it just means that the program might not be
> single threaded and that more care is needed.

Jakub,

Thanks, I didn't notice that. I see that ntpl/pthreadP.h does describe
the equivalent global variable as "Variable set to a nonzero value if
more than one thread runs or ran." The "or ran" part was something I
didn't know.

Richard,

Thanks for pointing out useless busy work. I thought there might be
value in eventually differentiating from "Is cancellation possible?"
vs. "Have other threads run?" given that often I've wanted to disable
cancellation entirely for testing, but not disable other runtime
behaviour based on SINGLE_THREAD_P. I shouldn't offload that work onto
Siddhesh.

Siddhesh,

I would be OK with the original patch, but I would like more comments in:

* pthread_cancel, stating that exactly why we are touching multiple_threads.
* New comments in nptl/descr.h to document what multiple_threads means.
* Expand comment in nptl/pthreadP.h regarding __pthread_multiple_threads.
* Expand comment in nptl/vars.c regarding __pthread_multiple_threads.
* New comments in nptl/sysdeps/unix/sysv/linux/libc_multiple_threads.c
regarding __libc_multiple_threads.

I would still like the test case to be expanded to cover more cases in
the event that it reveals something we didn't think about.

Does that sound OK?

Cheers,
Carlos.