Consider removing Core::id.

[carllerche]

I'm not sure exactly why it was added in the first place. Specifically, I know it was added to provide some token to use as a map key, but I don't recall the exact scenario that required this to be in the library.

The implementation also doesn't handle usize wrapping, which is a very edge case, but it seems like it should be handled.

Basically, enough has changed w/ the usage patterns of how the reactor should be used that I would like to remove Core::id from the initial release and re-evaluate if it is needed.

[aturon]

Fine by me.

[alexcrichton]

This was originally added in tokio-rs/tokio-core#149 to solve tokio-rs/tokio-core#147 which was in turn targeted at alexcrichton/tokio-signal#6 which removed the need for keeping the original event loop alive once you're creating signal handlers.

With no ability to spawn this doesn't really make any more sense as the whole point was to "spawn a thing per event loop" or "spawn one thing globally and only one". That being said I have no idea how this will actually get implemented for signal handling...

[carllerche]

I'm not sure what exactly requires one task per executor in order to handle signals (which is what it seems like it is trying to do).

My initial thought would be that logic that pushes signals to the associated streams would be handled the same way as timers.

[aturon]

In any case it seems prudent to start without it at first, and then revisit tokio-signal; it's easy to add back if needed.

[carllerche]

Fixed by #41