From 10f5229d4f0740c36e01f2e5ab35faefcec55eaa Mon Sep 17 00:00:00 2001
From: Zebediah Figura <z.figura12@gmail.com>
Date: Wed, 4 Jul 2018 14:58:33 +0200
Subject: [PATCH 66/83] esync: Update README.

---
 README.esync | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/README.esync b/README.esync
index 627cc3f48..30e241755 100644
--- a/README.esync
+++ b/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.
-- 
2.20.1

