EventMachine::attach_Server is for attaching an arbitrary server IO
object or file descriptor to the event loop.

Tries to fix eventmachine#93.

Signed-off-by: Ramon Marco L. Navarro <ramonmaruko@gmail.com>

Conflicts:
	README.md
	ext/cmain.cpp
	ext/ed.cpp
	ext/ed.h
	ext/eventmachine.h
	ext/rubymain.cpp
	tests/test_epoll.rb

FIXME: Why is handing a wrong argument to initialize a silent error?

…AP_NET_ADMIN or uid 0.

…e-tests

…atagram.

Note that EM.send_datagram does NEVER validate the given address.

Conflicts:
	tests/test_ipv6.rb

- eventmachine@287dd33
- eventmachine@f4145c4

Added Travis icon

Removed custom Github page (non mantained, let's use just the README).

I think this fixes issue eventmachine#441.

8b613d0 changed the `select` timeout to zero in the case where
NumCloseScheduled > 0. It seems that in certain circumstances (for
example, if `close_connection` is called in a connection's `unbind`)
NumCloseScheduled would get incremented twice, but only decremented
once, thus never again reaching zero for the lifetime of the reactor.

The user-observed effect was that one CPU core would be pegged at 100%,
because the zero `select` timeout caused us to go around the select loop
without any pause.

Changing it so that it is safe to ScheduleClose() multiple times seems
like the cleanest solution to the problem.

Make ScheduleClose() idempotent

…o (do not announce handskale completion). In that case invoke unbind() with error==EPROTO (protocol error).

- Improve gemspec.
- Version 1.1.7.