Task accounting statistics

[bblum]

It would be cool if the scheduler exposed statistics about tasks. Currently all I have in mind is time alive / time on CPU / time blocked.

[eholk]

It'd also be nice to be able to give tasks names.

[bblum]

oh, yeah, there's a hole for that already in the runtime code, just no way to do it.

[eholk]

Yeah, ideally we'd have task::set_name, but then we have to deal with passing strings to the runtime. It's not hard, but it's always enough to discourage me from it.

[bblum]

as_c_str, and strcpy on the runtime side? (well, strdup, probably)

[eholk]

I think that's basically it.

[bblum]

hey @eholk, what do you think of this scary comment in rust_task.h?

// Only a pointer to 'name' is kept, so it must live as long as this task.

EDIT: it's ok as is, because the only args are ever "main" or NULL. it's just hinting that it needs a strdup.

[eholk]

Yeah, I was thinking maybe just allocate a fixed sized char buffer and copy the string into it.

[graydon]

still valid, and I think important enough for production use (accounting / profiling of tasks in general) that I'm going to nominate for production ready.

[brson]

Some stats relevant to the new scheduler:

• Sends - can either rendezvous with the receiving task and context switch immediately or not
• Receive - can either block or not
• Work stealing - how many times schedulers become stealers, and how often this is successful
• I/O - how often outstanding I/O forces the scheduler to go into slower scheduling modes
• I/O affinity - how often tasks must be sent to other threads to satisfy I/O

[graydon]

accepted for well-covered milestone

[graydon]

See also #6810

[catamorphism]

Re-nominating in order to de-milestone this; we're trying to cut back the milestones to a more manageable size and this doesn't seem like a blocker to me.

[catamorphism]

Just a bug, de-milestoning

[reem]

Triage bump, fixed according to #2891

[thestinger]

#17325 means this isn't relevant to the standard libraries anymore. The usual profiling tools can be used with native threads and the libraries themselves won't have the necessary information.