Enhance thread API

[tzach]

Current thread API
http://osv.io/api/swagger-ui/dist/index.html#!/os.json/listThreads_get_10
capture minimal information per thread.
For monitoring and debugging it will be useful to include more information per thread:

"father": { "type": "long",
"description": "created by thread id" 
}, 
"priority": { "type": "float" }, 
"sched-policy": { "type": "long" }, 
"stack-size": { "type": "long" }, 
"status": { 
"type": "string", 
"description": "thread status", 
"enum": [ 
"invalid", 
"prestarted", 
"unstarted", 
"waiting", 
"running", 
"queued", 
"waking", 
"terminating", 
"terminated" 
] 

[tzach]

Partially implemented cloudius-systems/osv@340763c
@amnonh @nyh what about "father" thread info?

[nyh]

The parent thread info is problematic because although the parent exists at
the time it creates the child thread, a millisecond later the parent might
be gone. Several generations of parents might be gone.
Why do you want to know the parent? One reason is to sum up a whole tree
eg to sum up the cpu usage of an application. If that is the intended use
I suggest to add a rest api to get a thread's app id. We already have a c++
api for that.
On Aug 24, 2014 3:30 PM, "Tzach Livyatan" [email protected] wrote:

Partially implemented cloudius-systems/osv@340763c
cloudius-systems/osv@340763c
@amnonh https://github.com/amnonh @nyh https://github.com/nyh what
about "father" thread info?

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

[tzach]

The parent thread info is problematic because although the parent exists at
the time it creates the child thread, a millisecond later the parent might
be gone

Sadly, this may happened to every living thing
Still, we would like to know who are our parents
A more complete solution will be to keep a full pedigree, up to the original thread (Eve thread).

Why do you want to know the parent? One reason is to sum up a whole tree
eg to sum up the cpu usage of an application.

Yes

If that is the intended use
I suggest to add a rest api to get a thread's app id. We already have a c++
api for that.

What is the app granularity in this scope?
Is it the JVM, Cassandra?

[nyh]

On Aug 24, 2014 4:04 PM, "Tzach Livyatan" [email protected] wrote:

The parent thread info is problematic because although the parent exists
at
the time it creates the child thread, a millisecond later the parent
might
be gone

Sadly, this may happened to every living thing
Still, we would like to know who are our parents

If the parent of thread 123 is thread 77 but thread 77 is already dead you
lose the information of where in the tree 123 sits. This is why just
knowing the parent may not be enough.

A more complete solution will be to keep a full pedigree, up to the
original thread (Eve thread).

Yes possible.

Why do you want to know the parent? One reason is to sum up a whole tree
eg to sum up the cpu usage of an application.

Yes

If that is the intended use
I suggest to add a rest api to get a thread's app id. We already have a
c++
api for that.

What is the app granularity in this scope?
Is it the JVM, Cassandra?

The current notion of "app" involves running a .so. so we have for example
a run of java.so - a jvm and the java program it runs (eg cassandra) as one
app - while the kernel threads and httpserver (for example) are outside
this app.

—
Reply to this email directly or view it on GitHub.

[tzach]

A more complete solution will be to keep a full pedigree, up to the
original thread (Eve thread).

Yes possible.

Do you, or anyone else, see a value in keeping each thread ancestry?