esync: Update README.

README.esync

@@ -2,6 +2,29 @@ This is eventfd-based synchronization, or 'esync' for short. Turn it on with
 WINEESYNC=1 (note that it checks the presence and not the value); debug it
 with +esync.
 
+== BUGS AND LIMITATIONS ==
+
+Please let me know if you find any bugs. If you can, also attach a log with
++seh,+pid,+esync,+server.
+
+If you get something like "eventfd: Too many open files" and then things start
+crashing, you've probably run out of file descriptors. esync creates one
+eventfd descriptor for each synchronization object, and some games may use a
+large number of these.  Linux by default limits a process to 4096 file
+descriptors, which probably was reasonable back in the nineties but isn't
+really anymore. (Fortunately Debian and derivatives [Ubuntu, Mint] already
+have a reasonable limit.) To raise the limit you'll want to edit
+/etc/security/limits.conf and add a line like
+
+* hard nofile 1048576
+
+then restart your session.
+
+Also note that if the wineserver has esync active, all clients also must, and
+vice versa. Otherwise things will probably crash quite badly.
+
+== EXPLANATION ==
+
 The aim is to execute all synchronization operations in "user-space", that is,
 without going through wineserver. We do this using Linux's eventfd
 facility. The main impetus to using eventfd is so that we can poll multiple
@@ -135,8 +158,6 @@ surprisingly there aren't that many. In particular:
 
 There are some things that are perfectly implementable but that I just haven't
 done yet:
-* NtQuery*. That said, these APIs aren't exposed through kernel32 in any way, so
-  I doubt anyone is going to be using them.
 * Other synchronizable server primitives. It's unlikely we'll need any of
   these, except perhaps named pipes (which would honestly be rather difficult)
   and (maybe) timers.