Tweak the PollEvented::deregister signature

[alexcrichton]

This commit changes the PollEvented::deregister signature from

fn deregister(self, handle: &Handle) -> io::Result<()>

to

fn deregister(&self) -> io::Result<()>

Now that the handles are Send and Sync there's no longer any need to pass it
in (it's already stored in the PollEvented itself). Additionally this switches
to &self instead of self to allow reclamation of the internal resources if
necessary.

This PR is based on #54, only the last commit needs to be reviewed.

[cramertj]

Nice! Now that it no longer requires any external parameters, should deregister be removed then in favor of a Drop impl? tokio-rs/mio#753 brought up some issues that could be resolved by doing this.

[alexcrichton]

@cramertj perhaps yeah, but I think we'd still want deregister anyway b/c that way (on Unix at least) you could migrate objects between event loops (in theory at least). I've also personally been under the assumption so far that if you drop the PollEvented it internally drops the E which at the OS level implicitly performs deregistration so an explicit call isn't necessary.

That being said tokio-rs/mio#753 would of course change the calculus here quite a lot!

[cramertj]

@alexcrichton

that way (on Unix at least) you could migrate objects between event loops

I'd assume in order to do that you'd need a register function of some sort which takes a new Handle. If that's the case, you could call deregister internally prior to registering with the new event loop.

I've also personally been under the assumption so far that if you drop the PollEvented it internally drops the E which at the OS level implicitly performs deregistration so an explicit call isn't necessary.

That makes sense, but I think the conversation in tokio-rs/mio#753 and tokio-rs/mio#361 turned up that implicit deregistration doesn't work right if the underlying file descriptor has been duplicated.

[alexcrichton]

@cramertj oh I was also thinking we'd have something like into_inner eventually.

but I think the conversation in tokio-rs/mio#753 and tokio-rs/mio#361 turned up that implicit deregistration doesn't work right if the underlying file descriptor has been duplicated.

True, but we don't expose any apis that duplicate underlying file descriptors (precisely for this reason!) so if you get into that situation you're sort of "on your own" at that point anyway.

---

FWIW I believe the original motivation for a method like this was to deregister file descriptors in response to external runtimes like libcurl provides. Looking at tokio-curl today it doesn't actually use this though so maybe it migrated away at some point!

Regardless though I think for low-level functionality we'll want to retain functionality like this as it seems inevitable to come up at some point, although I could also imagine tweaking the signature of deregister or having more stern warnings about using the PollEvented after deregister has been called.

[cramertj]

@alexcrichton Okay! Seeing as tokio-rs/tokio-core#282 gets around this by not using PollEvented at all, I will plan to continue doing my own thing for Fuchsia and trust your judgement concerning other platforms :)

[alexcrichton]

Heh, true!