From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83235 invoked by alias); 29 Apr 2015 19:40:46 -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 83219 invoked by uid 89); 29 Apr 2015 19:40:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 29 Apr 2015 19:40:43 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 20.E5.06409.9FFC0455; Wed, 29 Apr 2015 14:35:06 +0200 (CEST) Received: from [142.133.110.232] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.210.2; Wed, 29 Apr 2015 15:40:41 -0400 Message-ID: <554133B8.5020004@ericsson.com> Date: Wed, 29 Apr 2015 22:44:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH] Cleanup num_found usage in gdb_wait_for_event References: <1430331569-17144-1-git-send-email-simon.marchi@ericsson.com> <55412EB9.7020206@redhat.com> In-Reply-To: <55412EB9.7020206@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01087.txt.bz2 On 15-04-29 03:19 PM, Pedro Alves wrote: > On 04/29/2015 07:19 PM, Simon Marchi wrote: >> Probably an artifact from the past, managing num_found in those loops is >> not need. >> >> Regtested on Ubuntu 14.04 x64, although only with use_poll == 1. >> >> gdb/ChangeLog: >> >> * event-loop.c (gdb_wait_for_event): Cleanup uneeded usages of >> num_found. > > Hmm, I'm not sure whether the state of poll_fds[i].revents is defined > if poll returns timeout or -1/EINTR, and it seems that with this change > we'll walk the poll_fds array on -1/EINTR. > > I was planning on sending this patch soon that touches this code, and > makes use of num_found: > > https://github.com/palves/gdb/commit/5652cc4487a1cc5e1d5ab85b64f325292fd059f2 > > Now I'm curious how you ran into this. > > Thanks, > Pedro Alves Oh well, I was investigating the exact same test failure (mi-nsmoribund.exp). It's failing maybe 90% of the time on our x86 Jenkins boxes. I was actually writing a patch for that at the moment. For poll, I keep a static variable around that tells which pollfd structure to start iterating from. So the first time we check 0, 1, 2, next time we'll check 1, 2, 0, then 2, 0, 1, etc. It's really simple. The static variable should be a field in gdb_notifier though. For select, I move the handled file_ptr at the end of the linked list, so that it has the least priority the next time around. You solution to keep a pointer to the first file_ptr to check next time is simpler though. Then you can just iterate on the list starting at that item, making sure you handle correctly the wrap at the end of the list. Here is my patch in raw form: https://github.com/simark/binutils-gdb/commit/ec49aaec6963f0aa974d183b8fca669f6261274d In any case, I don't see why interacting with num_found here is useful, given that we only handle one event. If we did handle all the found events, then I would understand, since you want to know when you are done.