From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12160 invoked by alias); 26 Sep 2019 17:36:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12151 invoked by uid 89); 26 Sep 2019 17:36:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:718, timer X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Sep 2019 17:36:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569519401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vgtczHwNNuOhGMn+Hatr03U22XsRqyE/5Kz3+aO/u5M=; b=Dycwg7VKrrmeBGalHFj6yb+MiKGVEN7c+QxKeUrOH6fkp562dJQoE03isPSQAjh7cehcFE X/LhpyxvoNdedUVX+Z8FyHIbKO8+x8uXXkUk25Z7JC0QaxGtr3gYjfaTnUQ/tICDTu7yUB nMDgseOc9931aEYkI5/nDqIy7q2xK+Q= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-94-exkTcwAyP-iwUZzm1pMqYA-1; Thu, 26 Sep 2019 13:36:39 -0400 Received: by mail-wm1-f70.google.com with SMTP id 4so1328164wmj.6 for ; Thu, 26 Sep 2019 10:36:38 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id u10sm6111001wrg.55.2019.09.26.10.36.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 10:36:37 -0700 (PDT) Subject: Re: [RFC 17/17] Simplify gdbserver's serial event handling To: Tom Tromey , gdb-patches@sourceware.org References: <20190224165153.5062-1-tom@tromey.com> <20190224165153.5062-18-tom@tromey.com> From: Pedro Alves Message-ID: Date: Thu, 26 Sep 2019 17:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190224165153.5062-18-tom@tromey.com> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-09/txt/msg00533.txt.bz2 On 2/24/19 4:51 PM, Tom Tromey wrote: > Currently, when gdbserver handles a serial event, it also calls > 'reschedule' to install a timer that is then used to process any data > that remains after the previous packet was processed. >=20 > It seemed better to me to simply have the file descriptor callback > loop, processing packets until complete. I would rather not do this change, because it potentially starves other event sources. I've had to fix starvation issues like that in several places in gdb throughout the years -- see url I pointed that justifying need for async serial events, random_pending_event_thread in infrun.c, etc. Thanks, Pedro Alves