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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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