Define Mio's behavior

[carllerche]

Exact mio behavior should be documented and consistent across platforms.

A few cases to document:

• A TcpStream is registered with an EventLoop, the EventLoop is closed, a new one is created and the socket is registered with the new one.
• A TcpStream is registered, then deregistered, then registered with a different EventLoop
• A socket is registered with multiple EventLoop values.
• what happens if you register or reregister a socket with EventSet::none()
• what happens if you close a socket without deregistering it
  • more events after the current tick finishes?
• Require readable or writable interest to be present in the EventSet
• Should TryRead & TryWrite take &mut self or &self?
• Should Poll be public and what should the API be. Can IoEvent be renamed to Event.
• What happens if a socket is registered with both edge & level (answer is probably: Error)
• What happens if you use the same token with multiple sockets.
  • look at kqueue implementation
  • Windows may also be a hazard here
• Deregistering a socket with an EventLoop that does not own it.
• Reregister before register #416
• Use Duration for timeouts?
• What happens when an IOCP handle is closed when there is active I/O?
• All types should be Sync and Send
  • use AtomicUsize on Unix with compare and swap + relaxed

[reem]

Other things:

• what happens if you register or reregister a socket with EventSet::none()
• what happens if you close a socket without deregistering it

EDIT: Now included in the top post.

[reem]

Also, given the recent changes for tracking the event loop a socket is registered on, do we care if mio's io objects are Sync?

[carllerche]

We probably do want them to be Sync. It'll be worth revisiting.

[carllerche]

Idea: type encode socket registration state: https://www.reddit.com/r/rust/comments/3vdz26/mio_v05_released_now_with_windows_support/cxn8p8t

[reem]

Do we care about defining the behavior of mio under fork? I know this is a place where kqueue and epoll differ rather significantly.

[danburkert]

Another thing:

• What happens when you read or write to a socket before the first readable or writable interest is fired?

At least for writing, it works fine on Linux. On OS X you are liable to get an io::Error with the message "Socket is not connected".

[carllerche]

Do we care about defining the behavior of mio under fork? I know this is a place where kqueue and epoll differ rather significantly.

Yeah.... not for 1.0 :) especially since that is a *nix specific use case. Do you happen to know what happens now?