Re: [PATCH] Fix mutex pretty printer test and pretty printer output.

[Torvald Riegel <triegel at redhat dot com>]

On Wed, 2017-01-11 at 11:07 -0300, Martin Galvan wrote:
> 2017-01-11 11:01 GMT-03:00 Torvald Riegel <triegel@redhat.com>:
> > 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).
> 
> Right. Will send a patch during this week.

Thanks.  It might be easiest if you just take my patch and improve it
with what we discussed so far.

> > 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.
> 
> Makes sense.
> 
> >> > 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.
> >
> > 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.
> 
> Ok. Will make it clear on the README, probably using the lock printers
> as just an example (since hopefully in the future we'll have printers
> for other modules as well :) )

I don't know whether other modules may make more promises (in
particular, mostly sequential code, where the state is described fully
by what a single thread can observe).  I was thinking only about pretty
printers for concurrent stuff when I wrote the goals above.