doc: trim down documentation slightly

The "threads:" option for the "listen" directive is worthless.
Having a dedicated thread per-process is already more than enough
(and ideal) for a multi-process setup.  Multiple acceptor threads
is still wrong for a single-process setup (even if we did not
have a GVL) as it still incurs contention with the worker
pool within the kernel.

So remove the documentation regarding "listen ... threads: ",
for now; at least until somebody can prove it's useful and not
taking up space.

Additionally, "atfork_parent" may be useful for restarting
background threads/connections if somebody wants to run
background jobs in the master process, so stop saying
it's completely useless.

1 files changed, 0 insertions, 17 deletions

diff --git a/Documentation/yahns_config.pod b/Documentation/yahns_config.pod
index ff04cb3..12ec75e 100644
--- a/Documentation/yahns_config.pod
+++ b/Documentation/yahns_config.pod
@@ -422,22 +422,6 @@ ref: https://lwn.net/Articles/542629/
 
 Default: false (unset)
 
-=item threads: INTEGER
-
-Used to control the number of threads blocking on the L<accept(2)>
-or L<accept4(2)> system call (per listen socket).
-
-Usually, only one thread here is necessary, especially when
-multiple worker_processes are configured (as there'll be one
-thread per-process).  Having extra threads may increase
-contention with epoll and FD allocation within one process.
-
-Note: do not confuse this option with worker_threads for queues,
-each queue has their own thread pool and it makes sense to
-have multiple threads there.
-
-Default: 1
-
 =item umask: MODE
 
 Sets the file mode creation mask for UNIX sockets.  If specified,
@@ -584,7 +568,6 @@ Default: none
 =item atfork_parent &BLOCK
 
 This &BLOCK is executed in the parent after the L<fork(2)> operation.
-This may not be useful, but exists in case somebody finds a use for it.
 
 Default: none