This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Cleanup num_found usage in gdb_wait_for_event
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 29 Apr 2015 15:40:40 -0400
- Subject: Re: [PATCH] Cleanup num_found usage in gdb_wait_for_event
- Authentication-results: sourceware.org; auth=none
- References: <1430331569-17144-1-git-send-email-simon dot marchi at ericsson dot com> <55412EB9 dot 7020206 at redhat dot com>
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.