From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116852 invoked by alias); 15 Nov 2019 17:35:40 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 116842 invoked by uid 89); 15 Nov 2019 17:35:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=notified X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 17:35:38 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 7B3AB3000275; Fri, 15 Nov 2019 18:35:35 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 612D34000FF8; Fri, 15 Nov 2019 18:35:35 +0100 (CET) Message-ID: Subject: Re: patch 3/3 debuginfod client interruptability From: Mark Wielaard To: Aaron Merey Cc: "Frank Ch. Eigler" , elfutils-devel@sourceware.org Date: Fri, 15 Nov 2019 17:35:00 -0000 In-Reply-To: References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <20191028190726.GE14349@redhat.com> <20191104214823.GA17633@redhat.com> <73de7c5ac7205dbb5e6d4c47a2abb0c23cd79d5e.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00145.txt.bz2 Hi Aaron, On Fri, 2019-11-15 at 12:03 -0500, Aaron Merey wrote: > On Fri, Nov 15, 2019 at 11:16 AM Mark Wielaard wrote: > > On Mon, 2019-11-04 at 16:48 -0500, Frank Ch. Eigler wrote: > > > At the wise counsel of gdb folks such as and : > > >=20 > > > debuginfod 3/3: client interruptability > > >=20 > > > For interactive clients such as gdb, interruptibility is importan= t for > > > usability during longer downloads. This patchset adds a > > > download-progress callback function to the debuginfod client libr= ary, > > > with which a caller app can interrupt a download as well as be > > > notified of its quantitative progress. > >=20 > > I have some concerns about this. It cannot be associated with a > > particular debuginfod-find request. >=20 > Good point, maybe we should add a progress function to debuginfo-find, > or include a default progress function with libdebuginfod. Maybe one > that prints the url where the target was found plus the download > completion percentage every few seconds. >=20 > > IMHO it should have an extra argument to indicate which build-id > > and request type exec, debug or source (+path) the progress/callback > > was for. >=20 > I think we could add this information to the progress function output > without changing the API. But if users would like more control over > how this information gets used in the progress func maybe it's > worth considering. >=20 > > Also this one global progress/interruptable hook. Which means it > > cannot be used by e.g. libdw and an application that uses both > > libdw and find-debuginfo directly. >=20 > I wonder how often this kind of situation will come up. If it's very > infrequent maybe it's enough to simply flag this issue in the docs > so users know to avoid it. I think it is pretty common these days. People reuse libraries, which use libraries themselves and more and more programs will use multiple threads of execution. IMHO it would be best to avoid any global state from the start. Since we haven't released this api yet we can make it so that it is easy to have state per request object. In the gdb thread=20 https://sourceware.org/ml/gdb-patches/2019-11/msg00118.html Simon Marchi suggested something like: debuginfod_client *client =3D debuginfod_create_client (); debuginfod_set_progressfn (client, my_progress_cb); With debuginfod_client * being an opaque pointer. I think that is a good idea. It also matches what libelf (with Elf *) and libdw (with Dwarf *) do. It also makes it easy to add other kinds of state to client requests later. Cheers, Mark