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] Fix mutex pretty printer test and pretty printer output.


On Wed, 2017-01-11 at 09:45 -0300, Martin Galvan wrote:
> 2017-01-11 7:32 GMT-03:00 Torvald Riegel <triegel@redhat.com>:
> > Do you have a concrete suggestion for alternative wording, or do you
> > think that "(if known)" is okay?
> 
> Perhaps there could be a check for __owner being zero, and in that
> case print "unknown" instead of "0".

Works for me, though I guess it should take the current state into
account too (ie, if it's not acquired, it shouldn't print unknown).

> That way we could drop the "(if
> known)". Maybe we could check whether __elision  exists and inform the
> user that lock elision is enabled, so that they have a better idea of
> what's going on. What do you think?

I'd like to have as little dependency on implementation internals as
possible.  One reason is that the internals might change, and although
we don't promise stability of the pretty printer output, every change
there causes at least some cost on the users' side.

Also, for example, if there is a performance advantage for not setting
the owner field on mutex types where this is possible, I would stop
setting it.

> > 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.
> 
> I thought that was implicitly clear. Printers exist precisely to
> abstract away the implementation details of the sync constructs, and
> yes, some details might be left off. If the user wants to know what's
> going on under the hood, they can just disable the printers and try to
> make sense of what gdb shows.

I'm not quite sure it's implicitly clear.  I suppose many people will
try to interpret it and use it to understand why there program doesn't
work.  I don't want to get bug reports caused by people reading more
into the pretty printers' output than what we promise; that's why I
suggested to make this explicit.


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