ev_io - is this file descriptor readable or writable?ev_io - is this file descriptor readable or writable?
+
+ev_timer - relative and optionally repeating timeoutsev_periodic - to cron or not to cron?ev_signal - signal me when a signal gets signalled!Some backends (e.g kqueue, epoll) need to be told about closing a file
+descriptor (either by calling close explicitly or by any other means,
+such as dup). The reason is that you register interest in some file
+descriptor, but when it goes away, the operating system will silently drop
+this interest. If another file descriptor with the same number then is
+registered with libev, there is no efficient way to see that this is, in
+fact, a different file descriptor.
To avoid having to explicitly tell libev about such cases, libev follows
+the following policy: Each time ev_io_set is being called, libev
+will assume that this is potentially a new file descriptor, otherwise
+it is assumed that the file descriptor stays the same. That means that
+you have to call ev_io_set (or ev_io_init) when you change the
+descriptor even if the file descriptor number itself did not change.
This is how one would do it normally anyway, the important point is that +the libev application should not optimise around libev but should leave +optimisations to libev.
+ + + +