From: Torvald Riegel <triegel@redhat.com>
To: Martin Galvan <omgalvan.86@gmail.com>
Cc: GLIBC Devel <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Fix mutex pretty printer test and pretty printer output.
Date: Wed, 11 Jan 2017 14:23:00 -0000 [thread overview]
Message-ID: <1484144588.5606.271.camel@redhat.com> (raw)
In-Reply-To: <CAN19L9EK3jsESk6pqPQhWmzMJ=xRqdoZ_W6WuaDRp9+DkjC2DQ@mail.gmail.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.
prev parent reply other threads:[~2017-01-11 14:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 16:11 Torvald Riegel
2017-01-10 16:39 ` Martin Galvan
2017-01-11 10:32 ` Torvald Riegel
2017-01-11 12:45 ` Martin Galvan
2017-01-11 12:49 ` Martin Galvan
2017-01-11 14:01 ` Torvald Riegel
2017-01-11 14:08 ` Martin Galvan
2017-01-11 14:23 ` Torvald Riegel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1484144588.5606.271.camel@redhat.com \
--to=triegel@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=omgalvan.86@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).