From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21290 invoked by alias); 13 Jun 2016 18:16:27 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17920 invoked by uid 89); 13 Jun 2016 18:16:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=trips, our X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 13 Jun 2016 18:16:15 +0000 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5DIGCVP002900 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Jun 2016 14:16:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5DIGCVP002900 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u5DIGCVP002900 Received: from mailsyshubprd51.lss.emc.com (mailsyshubprd51.lss.emc.com [10.106.48.26]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Mon, 13 Jun 2016 14:15:18 -0400 Received: from usendtaylorx2l (d5170089.lss.emc.com [10.243.146.89]) by mailsyshubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5DIFstP019387; Mon, 13 Jun 2016 14:15:54 -0400 Received: by usendtaylorx2l (Postfix, from userid 26043) id 185C12614CD; Mon, 13 Jun 2016 14:15:53 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l (Postfix) with ESMTP id F163D260847; Mon, 13 Jun 2016 14:15:53 -0400 (EDT) From: David Taylor To: gdb@sourceware.org cc: dtaylor@emc.com Subject: why I dislike qXfer Date: Mon, 13 Jun 2016 18:16:00 -0000 Message-ID: <31527.1465841753@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd53.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00020.txt.bz2 There are a number of remote protocol packets of the form qXfer:object:read:annex:offset,length For some object or object/annex combinations, this is a reasonable interface -- for example, when it is referring to data that does not change (and often it will reasonably fit within a single remote protocol reply packet). An example would be qXfer:features. My expectation is that if we implement this that it will be compiled in strings. Unless you connect to a different target or load new code on the target, it is not going to change. A board has a set of features and it doesn't typically change. But, there are some objects for which it is, in my opinion, a poor interface. For concreteness, consider the 'threads' object -- as it is the one I'm currently wrestling with. Threads come and go. And the amount of information I want to return per currently existing thread means that number of threads * bytes of info per thread exceeds the maximum packet size. So, multiple requests have to be issued to get everything. The system native format for the information is, of course, not XML. The per-thread data is variable length (e.g., the name field and, in our case, the 'extra information'). I want to always return the most current information. I want to return information on as many threads as possible. And I want to minimize the bookkeeping required. So, while I can avoid having to store the current position, if I am going to minimize bookkeeping and return the latest information, I have to pad each entry to the same size and cannot skip empty (read: dead thread) entries in the system process table. If the goal is to speed things up by, in part, having fewer network round trips, having to pad is not a win. With the qT{f,s}{STM,P,V} q{f,s}ThreadInfo (and possibly others) interfaces, nothing needs to be precomputed, and I either start at the beginning (f -- first) or where the previous request left off (s -- subsequent). I have to store, per connection, my location. But, there is no random reading. The next request of that flavor will either start at the beginning (f) or where the last one left off (s). Reads are sequential. With the offset,length interface I don't know that reads will be sequential so I need to pad and leave gaps. What do people do?