gdb: optimize selection of resumed thread with pending event

Consider a case where many threads (thousands) keep hitting a breakpoint
whose condition evaluates to false.  random_pending_event_thread is
responsible for selecting a thread from an inferior among all that are
resumed with a pending wait status.  It is currently implemented by
walking the inferior's thread list twice: once to count the number of
candidates and once to select a random one.

Since we now maintain a per target list of resumed threads with pending
event, we can implement this more efficiently by walking that list and
selecting the first thread that matches the criteria
(random_pending_event_thread looks for an thread from a specific
inferior, and possibly a filter ptid).  It will be faster especially in
the common case where there isn't any resumed thread with pending
event.  Currently, we have to iterate the thread list to figure this
out.  With this patch, the list of resumed threads with pending event
will be empty, so it's quick to figure out.

The random selection is kept, but is moved to
process_stratum_target::random_resumed_with_pending_wait_status.  The
same technique is used: do a first pass to count the number of
candidates, and do a second pass to select a random one.  But given that
the list of resumed threads with pending wait statuses will generally be
short, or at least shorter than the full thread list, it should be
quicker.

Note that this isn't completely true, in case there are multiple
inferiors on the same target.  Imagine that inferior A has 10k resumed
threads with pending wait statuses, and random_pending_event_thread is
called with inferior B.  We'll need to go through the list that contains
inferior A's threads to realize that inferior B has no resumed threads
with pending wait status.  But I think that this is a corner /
pathological case.  And a possible fix for this situation would be to
make random_pending_event_thread work per-process-target, rather than
per-inferior.

Change-Id: I1b71d01beaa500a148b5b9797745103e13917325

0 files changed, 0 insertions, 0 deletions