--- libev/ev_iouring.c	2019/12/20 05:20:23	1.6
+++ libev/ev_iouring.c	2019/12/22 15:05:32	1.7
@@ -49,8 +49,9 @@
  * e) why 3 mmaps instead of one? one would be more space-efficient,
  *    and I can't see what benefit three would have (other than being
  *    somehow resizable/relocatable, but that's apparently not possible).
+ *    (FIXME: newer kernels can use 2 mmaps only, need to look into this).
  * f) hmm, it's practiclaly undebuggable (gdb can't access the memory, and
-      the bizarre way structure offsets are commuinicated makes it hard to
+ *    the bizarre way structure offsets are communicated makes it hard to
  *    just print the ring buffer heads, even *iff* the memory were visible
  *    in gdb. but then, that's also ok, really.
  * g) well, you cannot specify a timeout when waiting for events. no,
@@ -60,8 +61,10 @@
  *    like a µ-optimisation by the io_uring author for his personal
  *    applications, to the detriment of everybody else who just wants
  *    an event loop. but, umm, ok, if that's all, it could be worse.
+ *    (FIXME: jens mentioned timeout commands, need to investigate)
  * h) there is a hardcoded limit of 4096 outstanding events. okay,
  *    at least there is no arbitrary low system-wide limit...
+ *    (FIXME: apparently, this was increased to 32768 in later kernels(
  * i) unlike linux aio, you *can* register more then the limit
  *    of fd events, and the kernel will "gracefully" signal an
  *    overflow, after which you could destroy and recreate the kernel
@@ -69,6 +72,7 @@
  *    totally insane, but kind of questions the point a high
  *    performance I/O framework when it doesn't really work
  *    under stress.
+ *    (FIXME: iouring should no longer drop events, need to investigate)
  * j) but, oh my! is has exactly the same bugs as the linux aio backend,
  *    where some undocumented poll combinations just fail.
  *    so we need epoll AGAIN as a fallback. AGAIN! epoll!! and of course,