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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2577 bytes --]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Thursday, July 19, 2012 8:45 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org; markus.t.metzger@gmail.com; Pedro Alves (palves@redhat.com)
> Subject: Re: [PATCH 1/1] gdb, python: update threads in Inferior.threads ()
> 
> 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.

I expected python scripts to store the thread list and only query it when the script doesn't know whether the thread list changed.
Of course, if you repeatedly issue a command instead of reusing the previously computed result, you pay for it.

Currently, python scripts would do gdb.execute ("info threads", False, True) before inferior.threads () to work around the problem.
This would be even worse.


> > > 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.

I am wondering whether gdbserver should notify gdb about new threads via an event. This would obsolete update_thread_list ().

Regards,
Markus.


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 350 bytes --]

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, Christian Lamprechter
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052