Re: What to call a thread/cpu/?

[Fernando Nasser <fnasser at redhat dot com>]

Well,

Using "threads" for processors started as a hack and evolved to the
right thing (or is evolving).  One day we should be able to handle
several different kinds of "threads": processors, kernel threads,
user-level threads.

I suggest we add an attribute to the current "threads" (after renaming
it to something, lets say xcontext (for "execution context")):

enum xcontext_type possible values:

   processor  - a cpu in a multiprocessor
   kthread  -  a kernel level thread
   uthread  -  a user level thread
   
The distinction may be useful.

Fernando


Andrew Cagney wrote:
> 
> Hello,
> 
> At present gdb has this thing called ``struct thread_info *''.  It
> *should* contains several key GDB data structures including:
> 
>         o       debug state
> 
>                 What GDB things it is doing
>                 to the thread - is it being
>                 stepped
> 
>         o       target state
> 
>                 registers, memory, all that suff
> 
> (it doesn't but that is another story :-)
> 
> The thing to realise is that GDB can be used to debug not only threads
> but also hardware CPUs.  Given that, the term ``thread'' is starting to
> struggle and is showing signs of being very overloaded.
> 
> The question is, what internal name should GDB use when refering to a
> thread/cpu/... or should it just stick to thread?
> 
> I've seen suggested/used:
> 
>         state
>         context
>         thread
>         target
>         inferior
> 
> You don't get to win a prise for comming up with the name but you do get
> the chance to be able to show GDB to your grand children and say ``hey I
> named that object'' :-)
> 
>         Andrew

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9