From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44711 invoked by alias); 11 Jan 2017 10:32:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 44700 invoked by uid 89); 11 Jan 2017 10:32:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Understanding, galvan, Galvan, H*M:245 X-HELO: mx1.redhat.com Message-ID: <1484130735.5606.245.camel@redhat.com> Subject: Re: [PATCH] Fix mutex pretty printer test and pretty printer output. From: Torvald Riegel To: Martin Galvan Cc: GLIBC Devel Date: Wed, 11 Jan 2017 10:32:00 -0000 In-Reply-To: References: <1484064691.5606.208.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00184.txt.bz2 On Tue, 2017-01-10 at 13:38 -0300, Martin Galvan wrote: > Thanks a lot for doing this; I was about to start working on something similar. > > If I might make a suggestion: "Owner ID (if known)" doesn't really > help the user understand what's happening when the mutex is acquired > but the owner isn't recorded. If it's zero, it may not be known. Understanding why would require explaining details of the mutex implementation. Do you have a concrete suggestion for alternative wording, or do you think that "(if known)" is okay? > I'd say we should at least document this > case somewhere (perhaps in the README?). I can write that myself if > you want to. Maybe. If you want to go ahead and explain what the pretty printers reveal, and how they should not be misunderstood (which is an important part of this -- users should be aware that they get simplified information), then please propose a patch. It might also be worth to clearly state the design goals for the pretty printers, which in my opinion is roughly: * Provide simplified information about the state of synchronization constructs to users. * There is no guarantee that this information is complete and covers everything a particular thread might do (e.g., the pretty printers do not show if a thread is spin-waiting in an attempt to acquire a mutex). * It is not aimed at understanding the details of the implementation of the synchronization construct.