This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #13613] Allow a single-threaded process to cancelitself
On 05/09/12 10:28, Carlos O'Donell wrote:
> On Wed, May 9, 2012 at 11:51 AM, Siddhesh Poyarekar
> <firstname.lastname@example.org> wrote:
>> On 9 May 2012 21:00, Carlos O'Donell <email@example.com> wrote:
>>> * After calling pthread_cancel() *all* of the optimizations that could
>>> have used SINGLE_THREAD_P are not available, not just those related to
>> 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.
>>> * 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:
>> int __multiple_threads;
>> int __enable_cancellation_points;
>> } cancellation;
>> #define multiple_threads cancellation.__multiple_threads
>> #define 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:
and avoid the needless macros.