Re: [PATCH 1/1] gdb, python: update threads in Inferior.threads ()

Jan Kratochvil
2012-07-19T18:45:43Z

On Thu, 19 Jul 2012 17:26:17 +0200, Metzger, Markus T wrote:
> > So far update_thread_list is called only before (in) the commands which really
> > need the thread list. The problem is that infpy_threads can be called from
> > a script repeatedly which may be pretty inefficient to call update_thread_list
> > each time.
>
> So it is the right place - just not a good one.
>
> Those scripts will now do "info threads" to achieve the same effect.

Not sure if we understand each other.

If I do GDB script:
while 1
info threads
end

Then it is needlessly inefficient, stopped inferior cannot change threads list
while this loop will re-scan the threads each time. But I do not think that
is a problem, 'info threads' is usually executed only after inferior has run
for a bit.

Contrary to it I can imagine Python script doing
gdb.selected_inferior().threads() a lot of times without running the inferior.

Maybe this GDB scripting vs. Python scripting difference is not significant.

> > The right would be to:
> > (1) Support update_thread_list per-inferior, not just for all inferiors at
> > once. For example infpy_threads is interested only in specific inferior.
> > (2) Cache the current thread list in struct inferior, clearing it from
> > begin of target_resume according to PTID (which depends for example on
> > 'set schedule-multiple', see user_visible_resume_ptid), therefore either
> > the specific inferior only or all inferiors.
>
> Shouldn't this rather be an event?

I do not understand here. Even is Python specific, caching of threads list
would be good to have even in non-Python GDB.

Thanks,
Jan