What happens when the runtime runs out of task ids?

[brson]

Currently the runtime assigns task id's (intptr_t) to each task, starting at 0. When the current task id hits INTPTR_MAX the runtime theoretically fails an assert and crashes. Would be sweet if the runtime didn't crash in this situation. Ports within a single task also have a similar problem, and soon schedulers will as well.

[bnoordhuis]

It's probably a naive question but why don't you change rust_task_id to uint64_t and call it a day? I can see 2^31 overflowing given enough time but 2^64?

[brson]

That sounds like a reasonable solution to me.

[brson]

I tried to implement this and hit some weird test failures on windows. Didn't investigate further.

[thestinger]

@brson: is this still an issue? it seems like the scheduler could use the address of the first stack segment as a unique identifier

[toddaaro]

Stumbled across this. The newsched runtime doesn't actually have task ids, so this shouldn't be a bug anymore. @brson, should we just close it?

If task ids do end up a concept again, they will likely be a concept in a library wrapping tasks with "fun features", and so not the domain of the core runtime.

[brson]

Obsolete in the new runtime.