yahns Ruby server user/dev discussion
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: yahns-public@yhbt.net
Subject: [PATCH 1/2] doc: trim down documentation slightly
Date: Sun, 14 Feb 2016 11:29:55 +0000	[thread overview]
Message-ID: <20160214112955.GA17758@dcvr.yhbt.net> (raw)
In-Reply-To: <20160214112856.GA17497@dcvr.yhbt.net>

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.
---
 Documentation/yahns_config.pod    | 17 -----------------
 examples/yahns_rack_basic.conf.rb |  2 +-
 test/test_server.rb               |  8 ++++----
 3 files changed, 5 insertions(+), 22 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
 
diff --git a/examples/yahns_rack_basic.conf.rb b/examples/yahns_rack_basic.conf.rb
index 12bbc99..33ba619 100644
--- a/examples/yahns_rack_basic.conf.rb
+++ b/examples/yahns_rack_basic.conf.rb
@@ -16,7 +16,7 @@
     puts "#$$ yahns parent about to spawn"
   end
   atfork_parent do
-    puts "#$$ this is probably not useful"
+    puts "#$$ yahns parent done spawning"
   end
 end
 
diff --git a/test/test_server.rb b/test/test_server.rb
index 65a6ea1..87193e3 100644
--- a/test/test_server.rb
+++ b/test/test_server.rb
@@ -428,7 +428,7 @@ def test_mp_hooks
         worker_processes(1) do
           atfork_child { puts "af #$$ worker is running" }
           atfork_prepare { puts "af #$$ parent about to spawn" }
-          atfork_parent { puts "af #$$ this is probably not useful" }
+          atfork_parent { puts "af #$$ parent done spawning" }
         end
       }
       stderr_path err.path
@@ -457,7 +457,7 @@ def test_mp_hooks
     assert_equal("af #{pid} parent about to spawn", lines.shift)
 
     # child/parent ordering is not guaranteed
-    assert_equal 1, lines.grep(/\Aaf #{pid} this is probably not useful\z/).size
+    assert_equal 1, lines.grep(/\Aaf #{pid} parent done spawning\z/).size
     assert_equal 1, lines.grep(/\Aaf #{worker_pid} worker is running\z/).size
   ensure
     quit_wait(master_pid)
@@ -479,7 +479,7 @@ def test_mp_hooks_worker_nr
         worker_processes(1) do
           atfork_child { |nr| puts "af.#{nr} #$$ worker is running" }
           atfork_prepare { |nr| puts "af.#{nr} #$$ parent about to spawn" }
-          atfork_parent { |nr| puts "af.#{nr} #$$ this is probably not useful" }
+          atfork_parent { |nr| puts "af.#{nr} #$$ parent done spawning" }
         end
       }
       stderr_path err.path
@@ -503,7 +503,7 @@ def test_mp_hooks_worker_nr
 
     # child/parent ordering is not guaranteed
     assert_equal 1,
-        lines.grep(/\Aaf\.0 #{pid} this is probably not useful\z/).size
+        lines.grep(/\Aaf\.0 #{pid} parent done spawning\z/).size
     assert_equal 1,
         lines.grep(/\Aaf\.0 #{worker_pid} worker is running\z/).size
   ensure
-- 
EW


  reply	other threads:[~2016-02-14 11:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-14 11:28 [PUSHED] doc: switch to perlpod (from pandoc-flavored Markdown) Eric Wong
2016-02-14 11:29 ` Eric Wong [this message]
2016-02-14 11:33 ` [PATCH 2/2] doc: document ssl_ctx for "listen" directive Eric Wong
2016-02-14 21:33 ` [PATCH 3/2] doc: various doc and linkification improvements Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/yahns/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160214112955.GA17758@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=yahns-public@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/yahns.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).