This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, May 10, 2012 at 9:18 AM, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> On Wed, 9 May 2012 13:28:40 -0400, Carlos wrote:
>> >> * It overloads multiple_threads with a new meaning i.e. "Is true if
>> >> either more than one thread is running or if the one thread called
>> >> pthread_cancel()", which is bad for maintainability.
>> >
>> > I agree. I think a union like:
>> >
>> > ? ? ?union
>> > ? ? ?{
>> > ? ? ? ?int __multiple_threads;
>> > ? ? ? ?int __enable_cancellation_points;
>> > ? ? ?} cancellation;
>> > ? ? ?#define multiple_threads cancellation.__multiple_threads
>> > ? ? ?#define enable_cancellation_points
>> > cancellation.__enable_cancellation_points
>> >
>> > this should work. Let me check.
>>
>> I like this better along with a comment describing why they share the
>> same variable, that way if we split them apart some day we'll know
>> what we need to do.
>>
>
> Looks like I'll need to refactor code to first rename SINGLE_THREAD_P
> to ASYNCCANCEL_DISABLED_P so that it gives the right idea to anyone who

Bike-shedding just a bit, this macro should not look like it is
testing to see if the thread cancellation state is set.

Why not ASYNCCANCEL_POSSIBLE_P? Which implies "Is it possible for
cancellation to occur?" With an appropriate comment about when it is
and is not possible e.g. when we have multiple threads, *or* just
before the main thread cancels itself.

> is reading. Currently from what I can tell, there are two distinct
> usages for tcbhead.multiple_threads, the first being wrapping syscalls
> around cancellation code and the second being to acquire locks before
> cmpxchg. These two usages assume distinct meaning only when the process
> is single-threaded, where cancellation is allowed but the process is
> still single-threaded. This will happen only during main thread
> cancellation and it doesn't really matter at that point since we're
> ending anyway, so for now it is best to have it represented by a single
> stored value.

That sounds good.

I think it will be interesting to be able to expose the ability to
globally disable the possibility of cancellation by splitting up the
union and providing an interface to this for the debugger.

> So I'll make this change in two parts, first by renaming
> SINGLE_THREAD_P and then adding something like the union above or even
> simply:
>
> #define enable_cancellation_points multiple_threads
>
> within the struct with a comment describing what they are. Sounds OK?

Yes it does.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]