Please make tokens consistent about mio HOT 4 CLOSED

I guess that mio has to use platform-dependent integers because the value of the token is stored in the internal data of epoll/kqueue, so there is no way to use a generic value, bigger than 32/64 bits.

Maybe, you can use a (really ugly) hack using a box and std::mem::transmute.

let my_data = box MyData::new(...);
let my_data_token: uint = unsafe { mem::transmute(my_data) };

from mio.

1. Before mentioned patch mio was using trait Token that allowed converting to uint, so no problem here.
2. Also, uint may or may not what you think it is. IIRC it's defined in Rust as minimum number enough to hold a pointer, which is not how it is defined in C/C++ - see e.g. discussion in https://github.com/1fish2/Rust-rfcs/blob/int-index-for-portability/active/0000-intindex.md

from mio.

The reason that I moved away from the generic for socket tokens was because

a) Like @ayosec mentioned, it is stored by epoll / kqueue and must be no bigger than a pointer size. As of now in the rust reference manual, uint is defined as the equivalent to C's uintptr_t, which is what is needed. If rust decides to change the meaning of uint, then Token will need to be updated to explicitly mean pointer sized.

b) There is no way to run drop functions correctly and any trait for the socket token would have to implement Copy.

Given these two requirements (and the inability to set size bounds on traits), it didn't seem worth making the socket token generic. I expect the main usage pattern will be to store of state in some structure and then pass the token to mio. As to why Token vs. just going w/ a raw number? I prefer making types specific to the use case at hand, but that might be personal preference.

Now, regarding why I didn't use Token across the board, the limitation is quite annoying, and I didn't see a reason to arbitrarily limit the the API. I completely disagree that it is of little use. I am finding it quite useful. Avoiding the double lookup when possible has benefits.

from mio.

There is no way to run drop functions correctly and any trait for the socket token would have to implement Copy.

Just to clarify, I believe what @carllerche is saying is that even though epoll removes closed FDs from the set, we have not found a reliable way to learn when an FD has been closed. This means that we have no way to drop tokens when the associated FD is no longer active, which will cause bad memory leaks.

from mio.