From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79073 invoked by alias); 18 Nov 2019 02:50:16 -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 79057 invoked by uid 89); 18 Nov 2019 02:50:16 -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=-8.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0 autolearn=ham version=3.3.1 spammy=concurrently, entrypoint X-Spam-Status: No, score=-8.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0 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: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 02:50:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574045413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TCB5+qas+1OgjXhPeW0GoOauOsif5JaFDvWFnDQ4c1o=; b=KsqDpDP87ZMZgcil2sPB3XLYQOYPrx9Ba/qfC90vSqOeWnvAyX+zHfumbgyhn74R9fYqID ZkEw8VvJKfBPlgK+IJxNH+kIXEZN86Vtq0PB4fO/golfkRI5sDUhmEzcD8eu1JIGXYJp7I 2y5oHYsBViGK14yPfcT16DLSUUcceCk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-KrTrPPluO2iph9tduSFLCw-1; Sun, 17 Nov 2019 21:50:12 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0B90E801FD2; Mon, 18 Nov 2019 02:50:11 +0000 (UTC) Received: from redhat.com (ovpn-116-19.phx2.redhat.com [10.3.116.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DA984101F6C1; Mon, 18 Nov 2019 02:50:10 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92) (envelope-from ) id 1iWX7B-0008Iv-1w; Sun, 17 Nov 2019 21:50:09 -0500 Date: Mon, 18 Nov 2019 02:50:00 -0000 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: Pedro Alves , Aaron Merey , elfutils-devel@sourceware.org Subject: Re: patch 3/3 debuginfod client interruptability Message-ID: <20191118025008.GA29713@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <20191028190726.GE14349@redhat.com> <20191104214823.GA17633@redhat.com> <73de7c5ac7205dbb5e6d4c47a2abb0c23cd79d5e.camel@klomp.org> <23bbcd14-fc4f-64f6-9a6a-af860b1018cb@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: KrTrPPluO2iph9tduSFLCw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00162.txt.bz2 Hi - > Attached is a variant that adds debuginfod_begin and debuginfo_end > (names matching elf/dwarf_begin/end) and adds a debuginfod_client > handle to each other function. Sure, if you like. Would you be sympathetic to supporting a client=3DNULL entrypoint to the lookup functions, ergo no begin/end, for applications that don't want a progressfn callback? That way the simple case looks simple. > I think the debuginfod_set_progressfn could use a bit more > documentation. It isn't immediately clear what a and b refer to. And > since we seem to use it in different phases maybe it needs an > "explanation message"? The man page covers it deliberately vaguely as a rough fraction: enough info to draw a progress bar, without tying us down to a a particular ABI. > diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx >=20=20 > +static debuginfod_client *client; Note that multiple http webapi handling threads may make federated debuginfod calls concurrently. Is it your idea that they share a single client object? - FChE