* [PATCH] Use std::vector in event-loop.cc
@ 2024-04-06 18:39 Tom Tromey
2024-04-08 4:32 ` Simon Marchi
2024-04-09 18:40 ` John Baldwin
0 siblings, 2 replies; 3+ messages in thread
From: Tom Tromey @ 2024-04-06 18:39 UTC (permalink / raw)
To: gdb-patches; +Cc: Tom Tromey
In my occasional and continuing campaign against realloc, this patch
changes event-loop.cc to use std::vector to keep track of pollfd
objects. Regression tested on x86-64 Fedora 38.
---
gdbsupport/event-loop.cc | 57 +++++++++++++---------------------------
1 file changed, 18 insertions(+), 39 deletions(-)
diff --git a/gdbsupport/event-loop.cc b/gdbsupport/event-loop.cc
index b18a9fdaac0..4f7ad36d8d6 100644
--- a/gdbsupport/event-loop.cc
+++ b/gdbsupport/event-loop.cc
@@ -112,8 +112,8 @@ static struct
file_handler *next_file_handler;
#ifdef HAVE_POLL
- /* Ptr to array of pollfd structures. */
- struct pollfd *poll_fds;
+ /* Descriptors to poll. */
+ std::vector<struct pollfd> poll_fds;
/* Next file descriptor to handle, for the poll variant. To level
the fairness across event sources, we poll the file descriptors
@@ -336,17 +336,11 @@ create_file_handler (int fd, int mask, handler_func * proc,
if (use_poll)
{
gdb_notifier.num_fds++;
- if (gdb_notifier.poll_fds)
- gdb_notifier.poll_fds =
- (struct pollfd *) xrealloc (gdb_notifier.poll_fds,
- (gdb_notifier.num_fds
- * sizeof (struct pollfd)));
- else
- gdb_notifier.poll_fds =
- XNEW (struct pollfd);
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->fd = fd;
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->events = mask;
- (gdb_notifier.poll_fds + gdb_notifier.num_fds - 1)->revents = 0;
+ struct pollfd new_fd;
+ new_fd.fd = fd;
+ new_fd.events = mask;
+ new_fd.revents = 0;
+ gdb_notifier.poll_fds.push_back (new_fd);
}
else
#endif /* HAVE_POLL */
@@ -426,28 +420,13 @@ delete_file_handler (int fd)
#ifdef HAVE_POLL
if (use_poll)
{
- int j;
- struct pollfd *new_poll_fds;
-
- /* Create a new poll_fds array by copying every fd's information
- but the one we want to get rid of. */
-
- new_poll_fds = (struct pollfd *)
- xmalloc ((gdb_notifier.num_fds - 1) * sizeof (struct pollfd));
-
- for (i = 0, j = 0; i < gdb_notifier.num_fds; i++)
- {
- if ((gdb_notifier.poll_fds + i)->fd != fd)
- {
- (new_poll_fds + j)->fd = (gdb_notifier.poll_fds + i)->fd;
- (new_poll_fds + j)->events = (gdb_notifier.poll_fds + i)->events;
- (new_poll_fds + j)->revents
- = (gdb_notifier.poll_fds + i)->revents;
- j++;
- }
- }
- xfree (gdb_notifier.poll_fds);
- gdb_notifier.poll_fds = new_poll_fds;
+ auto iter = std::remove_if (gdb_notifier.poll_fds.begin (),
+ gdb_notifier.poll_fds.end (),
+ [=] (const pollfd &item)
+ {
+ return item.fd == fd;
+ });
+ gdb_notifier.poll_fds.erase (iter, gdb_notifier.poll_fds.end());
gdb_notifier.num_fds--;
}
else
@@ -605,7 +584,7 @@ gdb_wait_for_event (int block)
else
timeout = 0;
- num_found = poll (gdb_notifier.poll_fds,
+ num_found = poll (gdb_notifier.poll_fds.data (),
(unsigned long) gdb_notifier.num_fds, timeout);
/* Don't print anything if we get out of poll because of a
@@ -676,7 +655,7 @@ gdb_wait_for_event (int block)
i = gdb_notifier.next_poll_fds_index++;
gdb_assert (i < gdb_notifier.num_fds);
- if ((gdb_notifier.poll_fds + i)->revents)
+ if (gdb_notifier.poll_fds[i].revents)
break;
}
@@ -684,12 +663,12 @@ gdb_wait_for_event (int block)
file_ptr != NULL;
file_ptr = file_ptr->next_file)
{
- if (file_ptr->fd == (gdb_notifier.poll_fds + i)->fd)
+ if (file_ptr->fd == gdb_notifier.poll_fds[i].fd)
break;
}
gdb_assert (file_ptr != NULL);
- mask = (gdb_notifier.poll_fds + i)->revents;
+ mask = gdb_notifier.poll_fds[i].revents;
handle_file_event (file_ptr, mask);
return 1;
}
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Use std::vector in event-loop.cc
2024-04-06 18:39 [PATCH] Use std::vector in event-loop.cc Tom Tromey
@ 2024-04-08 4:32 ` Simon Marchi
2024-04-09 18:40 ` John Baldwin
1 sibling, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2024-04-08 4:32 UTC (permalink / raw)
To: Tom Tromey, gdb-patches
On 2024-04-06 14:39, Tom Tromey wrote:
> In my occasional and continuing campaign against realloc, this patch
> changes event-loop.cc to use std::vector to keep track of pollfd
> objects. Regression tested on x86-64 Fedora 38.
This LGTM.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I almost commented to say that the `num_fds` could be removed, that you
could use the vector size instead. But then I saw that num_fds is also
used as the max fd number when using select. I then saw that I had an
old draft patch that would remove the select code in event-loop.cc and
elsewhere. The problem is that I don't remember the rationale for
starting such a patch. Probably that all platforms we support have
something better than select for event handling, but I don't know for
sure. But it would certainly help clean things up if we could remove
the select support.
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Use std::vector in event-loop.cc
2024-04-06 18:39 [PATCH] Use std::vector in event-loop.cc Tom Tromey
2024-04-08 4:32 ` Simon Marchi
@ 2024-04-09 18:40 ` John Baldwin
1 sibling, 0 replies; 3+ messages in thread
From: John Baldwin @ 2024-04-09 18:40 UTC (permalink / raw)
To: Tom Tromey, gdb-patches
On 4/6/24 2:39 PM, Tom Tromey wrote:
> In my occasional and continuing campaign against realloc, this patch
> changes event-loop.cc to use std::vector to keep track of pollfd
> objects. Regression tested on x86-64 Fedora 38.
A noble quest surely
Approved-By: John Baldwin <jhb@FreeBSD.org>
--
John Baldwin
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-09 18:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-06 18:39 [PATCH] Use std::vector in event-loop.cc Tom Tromey
2024-04-08 4:32 ` Simon Marchi
2024-04-09 18:40 ` John Baldwin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).