Get an ironclad guarantee about safety of TaskData

[rust-lang]

Get an ironclad guarantee about safety of TaskData

[MarkusJais]

Is recycling a Task necessary? After it is completed it might be better to create a new Task.
Or is recycling necessary for performance reasons if Task has a lot of internal data?

[alexcrichton]

Ah I wasn't thinking of recycling a task per-se but moreso if we accidentally re-use IDs. That is, I'd expect a server to be able to service more than 4B requests over its lifetime, so we'll probably recycle an id at some point (but not the task allocation itself)

[MarkusJais]

Ah, now I understand :-)
There is something like BigUint:
http://huonw.github.io/primal/num/bigint/struct.BigUint.html

Does the id have to be an int? What about UUID?

But both not optimal solutions as they would require more memory.

And UUIDs could collide although the risk is very, very small (but not strictly zero).

[alexcrichton]

It's true yeah, we could use something like a UUID with an incredibly large state space (to never overflow). The only restriction we have is we need the ability to atomically update it, but tbh a mutex here would be fine, so it's probably not a problem after all!

[MarkusJais]

The overhead of the mutex should be minimal or we might hit a wall under heavy load.

On the other hand, that could be a sign of bad architecture and using to many threads in the application.

If there are only as many threads as CPUs then a mutex that doesn't cover a lot of code might be perfectly fine.

[alexcrichton]

Ok, I think I've actually completely addressed this in 4be64f3, as we no longer need ids at all!

@aturon if you see this, we should talk very carefully about this API, and make sure I'm not going crazy.