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

[Richard Henderson <rth at twiddle dot net>]

On 05/09/12 10:28, Carlos O'Donell wrote:
> On Wed, May 9, 2012 at 11:51 AM, Siddhesh Poyarekar
> <siddhesh.poyarekar@gmail.com> wrote:
>> On 9 May 2012 21:00, Carlos O'Donell <carlos@systemhalted.org> wrote:
>>> * After calling pthread_cancel() *all* of the optimizations that could
>>> have used SINGLE_THREAD_P are not available, not just those related to
>>> cancellation.
>>
>> This should not make a difference, because a single thread cancelling
>> itself means that the process will end after unwind. For any
>> multi-threaded situation this does not make any difference since the
>> value was already 1.
> 
> OK, you've convinced me that performance is not a good argument.

Indeed.

>>> * 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.

... which to me means this change is just busy work.  I think the
comment in pthread_cancel ought to be sufficient.

If you insist on such a change, recall gcc's invisible unions:

  union {
     int multiple_threads;
     int enable_cancelation_points;
  };

and avoid the needless macros.


r~