public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Omar Sandoval <osandov@osandov.com>, elfutils-devel@sourceware.org
Subject: Re: [PATCH 3/5] libdwfl: add interface for attaching to/detaching from threads
Date: Wed, 30 Oct 2019 12:47:00 -0000	[thread overview]
Message-ID: <1ce04b119fd9f326a9a7a2d1c0630b45afe35f6e.camel@klomp.org> (raw)
In-Reply-To: <06926ca241daa563aba5398977b3d4acd70e47cd.1570438723.git.osandov@fb.com>

Hi Omar,

On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> libdwfl has implementations of attaching to/detaching from threads
> and
> unwinding stack traces. However, that functionality is only available
> through the dwfl_thread_getframes interface, which isn't very flexible.
> This adds two new functions, dwfl_attach_thread and dwfl_detach_thread,
> which separate the thread stopping functionality out of
> dwfl_thread_getframes. Additionally, it makes dwfl_thread_getframes
> cache the stack trace for threads stopped this way. This makes it
> possible to use the frames after dwfl_thread_getframes returns.

The advantage of the dwfl_thread_getframes interface is that you cannot
forget to "detach", so no Dwfl_Frames get dangling and (if the process
is life) you don't disrupt it more than necessary. This new interface
seems very simple to get wrong causing leaks and locking up
processes/threads.

Also, if we would adopt dwfl_attach_thread then I think it should take
a Dwfl_Thread object not a pid/tid as argument.

Could you provide some examples where this new interface/style is
beneficial?

Thanks,

Mark

  reply	other threads:[~2019-10-30 12:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07  9:05 [PATCH 0/5] libdwfl: expand stack frame interface Omar Sandoval
2019-10-07  9:05 ` [PATCH 5/5] libdwfl: add interface for evaluating DWARF expressions in a frame Omar Sandoval
2019-10-30 13:23   ` Mark Wielaard
2019-10-30 23:59     ` Omar Sandoval
2019-10-31 16:40       ` Mark Wielaard
2019-10-07  9:05 ` [PATCH 4/5] libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame Omar Sandoval
2019-10-30 13:04   ` Mark Wielaard
2019-10-30 23:55     ` Omar Sandoval
2019-10-31 16:29       ` Mark Wielaard
2019-10-07  9:05 ` [PATCH 2/5] libdwfl: only use thread->unwound for initial frame Omar Sandoval
2019-10-29 22:20   ` Mark Wielaard
2019-10-07  9:05 ` [PATCH 3/5] libdwfl: add interface for attaching to/detaching from threads Omar Sandoval
2019-10-30 12:47   ` Mark Wielaard [this message]
2019-10-30 23:49     ` Omar Sandoval
2019-10-31 16:21       ` Mark Wielaard
2019-10-31 17:13         ` Omar Sandoval
2019-10-07  9:05 ` [PATCH 1/5] libdwfl: don't bother freeing frames outside of dwfl_thread_getframes Omar Sandoval
2019-10-29 15:55   ` Mark Wielaard
2019-10-29 16:17     ` Omar Sandoval
2019-10-29 16:52       ` Mark Wielaard

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=1ce04b119fd9f326a9a7a2d1c0630b45afe35f6e.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=osandov@osandov.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).