pitchfork 0.16.0 → 0.17.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 96240978a658c76297ea22353c5851d80bee9f033a74420b025d9941e32476be
-  data.tar.gz: fb90757e6e6a86e31e43bfed1589ed8ecf95c5f3d6f7cbe9802e10f588dd68b8
+  metadata.gz: b22167ab418be7e6f7ad8a8c66177582b80e611423531f7f96f132688f684c8d
+  data.tar.gz: 036fbed35ccdece6c17b26f0f4011b78efcc33e4344e6fbe94fcb5ee170d52d3
 SHA512:
-  metadata.gz: bcfffa4d9e8cb3e92c3dbd89d5a3c32577e5170a039d0e3fd71d5b57b408c6d2cadaf2bb42009cc14714de75b60c42fe3e0273d01bf8f9d49777e09f4d137e2a
-  data.tar.gz: d663cbd0e73221ab8dff5dafb2696293cb2552d2026ae6faa0a4c4d28c61ae672d6745c1de5b52baaa5062c4d08ed2d0945ac0986e05cc20e62f713bb8fda84a
+  metadata.gz: cd7bd9b5ef42730eb970b368d18fc188834e65a8a7104666cf320d6ef71e629196dbab2ef081a11c988b5232de9084d7debe732ee306524dc503d7464f33823f
+  data.tar.gz: 53db8ad62bfdd0e21d8e01734427a9cc59a3594438b61616a2c0151dc563d5d2bc84521b1085ba797821598a8d35c9f95db12d50c3a909dfe03bc7834404c49b

data/.github/workflows/ci.yml

@@ -1,6 +1,12 @@
 ---
 name: Test
-on: [push, pull_request]
+
+on:
+  push:
+    branches:
+      - master
+
+  pull_request:
 
 jobs:
   ruby:
@@ -24,7 +30,7 @@ jobs:
     env:
       RACK_VERSION: "${{ matrix.rack }}"
       RUBYOPT: "${{ matrix.rubyopt }}"
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-22.04
     steps:
       - name: Check out code
         uses: actions/checkout@v4

data/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Unreleased
 
+# 0.17.0
+
+- Improve `Pitchfork::Info#live_workers_count` to be more accurate.
+- Refactor all server logs to be more consistent.
+- Add `setpgid` configuration option. When `false`, child processes are not reassigned to their own process group.
+  Necessary for initiating a debugging session in a child process (#148).
+- Assume config file is located at `config/pitchfork.rb` if `-c` argument isn't provided.
+- Remove `Pitchfork::Configurator#after_load` and `Pitchfork::Configurator#after_load=`, which have had no function since v0.1.0.
+- Fix a race condition triggered by a shutdown happening concurrently with a new mold initialization.
+
 # 0.16.0
 
 - Use `exit!` for exiting the middle process when forking a new worker or mold. 

data/Gemfile

@@ -2,7 +2,7 @@
 
 source "https://rubygems.org"
 
-gem 'minitest'
+gem 'megatest', '>= 0.1.1'
 gem 'rake'
 gem 'rake-compiler'
 if ENV["RACK_VERSION"]

data/README.md

@@ -18,10 +18,10 @@ both the request and response in between `pitchfork` and slow clients.
 * Shared-Nothing architecture: workers all run within their own isolated
   address space and only serve one client at a time for maximum performance
   and robustness. Concurrent requests don't need to compete for the GVL,
-  or impact each others latency when triggering garbage collection.
+  or impact each other's latency when triggering garbage collection.
   It also does not care if your application is thread-safe or not.
 
-* Reforking: `pitchfork` can be configured to periodically promote a warmed up worker
+* Reforking: `pitchfork` can be configured to periodically promote a warmed-up worker
   as the new template from which workers are forked. This dramatically improves
   the proportion of shared memory, making processes use only marginally more
   memory than threads would.
@@ -31,10 +31,10 @@ both the request and response in between `pitchfork` and slow clients.
 * Process management: `pitchfork` will reap and restart workers that
   die from broken apps. There is no need to manage multiple processes
   or ports yourself. `pitchfork` can spawn and manage any number of
-  worker processes you choose to scale to your backend.
+  worker processes you choose to scale your backend to.
 
-* Adaptative timeout: request timeout can be extended dynamically on a
-  per request basis, which allows to keep a strict overall timeout for
+* Adaptative timeout: request timeouts can be extended dynamically on a
+  per-request basis, which allows you to keep a strict overall timeout for
   most endpoints, but allow a few endpoints to take longer.
 
 * Load balancing is done entirely by the operating system kernel.
@@ -42,8 +42,8 @@ both the request and response in between `pitchfork` and slow clients.
 
 ## When to Use
 
-Pitchfork isn't inherently better than other Ruby application servers, it mostly
-focus on different tradeoffs.
+Pitchfork isn't inherently better than other Ruby application servers; it mostly
+focuses on different tradeoffs.
 
 If you are fine with your current server, it's best to stick with it.
 
@@ -52,7 +52,7 @@ If there is a problem you are trying to solve, please read the
 
 ## Requirements
 
-Ruby(MRI) Version 2.5 and above.
+Ruby(MRI) Version 2.5 or above.
 
 `pitchfork` can be used on any Unix-like system, however the reforking
 feature requires `PR_SET_CHILD_SUBREAPER` which is a Linux 3.4 (May 2012) feature.
@@ -93,7 +93,7 @@ address:port or a UNIX socket.
 
 ### Configuration File(s)
 
-`pitchfork` will look for the config.ru file used by rackup in APP_ROOT.
+`pitchfork` will look for the config.ru file used by rackup in `APP_ROOT`.
 
 For deployments, it can use a config file for pitchfork-specific options
 specified by the `--config-file/-c` command-line switch.
@@ -108,8 +108,8 @@ supported.  Run `pitchfork -h` to see command-line options.
 
 ## Relation to Unicorn
 
-Pitchfork initially started as a Unicorn patch, however some of Unicorn features
-as well as Unicorn policy of supporting extremely old Ruby version made it challenging.
+Pitchfork initially started as a Unicorn patch, however some Unicorn features
+as well as the Unicorn policy of supporting extremely old Ruby version made it challenging.
 
 Forking was the occasion to significantly reduce the complexity.
 
@@ -134,6 +134,6 @@ Thanks to Eric Wong and all Unicorn and Mongrel contributors over the years.
 Pitchfork would have been much harder to implement otherwise.
 
 Thanks to Will Jordan who implemented Puma's "fork worker" experimental feature
-which have been a significant inspiration for Pitchfork.
+which has been a significant inspiration for Pitchfork.
 
 Thanks to Peter Bui for letting us use the `pitchfork` name on Rubygems.

data/Rakefile

@@ -1,39 +1,28 @@
 # frozen_string_literal: true
 require "bundler/gem_tasks"
-require "rake/testtask"
 require "rake/extensiontask"
 
-Rake::TestTask.new("test:unit") do |t|
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList["test/unit/**/test_*.rb"]
-  t.options = '-v' if ENV['CI'] || ENV['VERBOSE']
-  t.warning = true
-end
-
-Rake::TestTask.new("test:integration") do |t|
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList["test/integration/**/test_*.rb"]
-  t.options = '-v' if ENV['CI'] || ENV['VERBOSE']
-  t.warning = true
-end
+require "megatest/test_task"
 
 namespace :test do
+  Megatest::TestTask.create(:unit) do |t|
+    t.tests = FileList["test/unit/**/test_*.rb"]
+    t.deps << :compile
+  end
+
+  Megatest::TestTask.create(:integration) do |t|
+    t.tests = FileList["test/integration/**/test_*.rb"]
+    t.deps << :compile
+  end
+
   # It's not so much that these tests are slow, but they tend to fork
   # and/or register signal handlers, so they if something goes wrong
   # they are likely to get stuck forever.
   # The unicorn test suite has historically ran them in individual process
   # so we continue to do that.
-  task slow: :compile do
-    tests = Dir["test/slow/**/*.rb"].flat_map do |test_file|
-      File.read(test_file).scan(/def (test_\w+)/).map do |test|
-        [test_file] + test
-      end
-    end
-    tests.each do |file, test|
-      sh "ruby", "-Ilib:test", file, "-n", test, "-v"
-    end
+  Megatest::TestTask.create(:slow) do |t|
+    t.tests = FileList["test/slow/**/test_*.rb"]
+    t.deps << :compile
   end
 
   # Unicorn had its own POSIX-shell based testing framework.

data/docs/CONFIGURATION.md

@@ -16,7 +16,7 @@ Each worker process will serve exactly one client at a time.
 
 ### `listen`
 
-By default pitchfork listen to port 8080.
+By default Pitchfork listens to port 8080.
 
 ```ruby
 listen 2007
@@ -25,19 +25,20 @@ listen 8080, tcp_nopush: true
 ```
 
 Adds an address to the existing listener set. May be specified more
-than once. address may be an Integer port number for a TCP port, an
+than once. The address may be an Integer port number for a TCP port, an
 `IP_ADDRESS:PORT` for TCP listeners or a pathname for UNIX domain sockets.
 
 ```ruby
 listen 3000 # listen to port 3000 on all TCP interfaces
-listen "127.0.0.1:3000"  # listen to port 3000 on the loopback interface
+listen "127.0.0.1:3000" # listen to port 3000 on the loopback interface
 listen "/path/to/.pitchfork.sock" # listen on the given Unix domain socket
 listen "[::1]:3000" # listen to port 3000 on the IPv6 loopback interface
 ```
 
 When using Unix domain sockets, be sure:
 1) the path matches the one used by nginx
-2) uses the same filesystem namespace as the nginx process
+2) to use the same filesystem namespace as the nginx process
+
 For systemd users using PrivateTmp=true (for either nginx or pitchfork),
 this means Unix domain sockets must not be placed in /tmp
 
@@ -152,7 +153,7 @@ The following options may be specified (but are generally not needed):
   disproportionally more requests than workers with higher PID.
   It generally isn't a problem, especially when reforking is enabled, but for
   applications that are routinely over provisioned, it may be desirable to
-  ensure all workers at least get some incoming requests so the can warm up.
+  ensure all workers at least get some incoming requests so they can warm up.
 
   Creating more than one queue allow to restrict which worker can process
   a given incomming request, hence making the load balancing fairer.
@@ -168,6 +169,18 @@ The following options may be specified (but are generally not needed):
 
   Default: `queues - 1`.
 
+- `setpgid: true or false`
+
+  When enabled, child processes will be made into a group leader with a pgid matching
+  their pid. The child process will no longer be in the foreground process group of
+  its control terminal.
+
+  This can break debugging sessions and interactive terminals inside the worker
+  processes. Set it to `false` if you need to activate a debugging session or read from
+  `STDIN` inside a worker process.
+
+  Default: `true` (enabled)
+
 - `umask: mode`
 
   Sets the file mode creation mask for UNIX sockets.
@@ -251,7 +264,7 @@ Due the low-complexity, low-overhead implementation, timeouts of less
 than 3.0 seconds can be considered inaccurate and unsafe.
 
 For running Pitchfork behind nginx, it is recommended to set
-"fail_timeout=0" for in your nginx configuration like this
+"fail_timeout=0" in your nginx configuration like this
 to have nginx always retry backends that may have had workers
 exit or be SIGKILL-ed due to timeouts.
 
@@ -295,14 +308,14 @@ The default Logger will log its output to STDERR.
 
 ## Callbacks
 
-Because pitchfork several callbacks around the lifecycle of workers.
+Pitchfork provides several callbacks hooks around the lifecycle of workers.
 It is often necessary to use these callbacks to close inherited connection after fork.
 
-Note that when reforking is available, the `pitchfork` monitor process won't load your application
+Note that when reforking is available, the Pitchfork monitor process won't load your application
 at all. As such for hooks executed in the monitor, you may need to explicitly load the parts of your
 application that are used in hooks.
 
-`pitchfork` also don't attempt to rescue hook errors. Raising from a worker hook will crash the worker,
+Pitchfork also doesn't attempt to rescue hook errors. Raising from a worker hook will crash the worker,
 and raising from a monitor hook will bring the whole cluster down.
 
 ### `after_monitor_ready`
@@ -312,13 +325,13 @@ spawning the original workers.
 
 ```ruby
 after_monitor_ready do |server|
-  server.logger.info("Monitor pid=#{Process.pid} ready")
+  server.logger.info("monitor pid=#{Process.pid} ready")
 end
 ```
 
 ### `before_fork`
 
-Called by the mold before forking a new workers, and by workers before they spawn a new mold.
+Called by the mold before forking new workers, and by workers before they spawn a new mold.
 
 ```ruby
 before_fork do |server|
@@ -417,16 +430,26 @@ By default the cleanup timeout is 2 seconds.
 Called in the monitor process when a worker hard timeout is elapsed:
 
 ```ruby
-after_worker_timeout do |server, worker|
+after_worker_hard_timeout do |server, worker|
   $stderr.puts "Worker hard timeout, pid=#{worker.pid}"
 end
 ```
 
 Once the callback complete, the worker will be signaled with `SIGKILL`.
 
-This callback being called in an indication that something is preventing the
+This callback being called is an indication that something is preventing the
 soft timeout from working.
 
+### `before_worker_exit`
+
+Called in the worker process before it is shut down.
+
+```ruby
+before_worker_exit do |server, worker|
+  server.logger.info("worker=#{worker.nr} shuts down after #{worker.requests_count} requests")
+end
+```
+
 ### `after_worker_exit`
 
 Called in the monitor process after a worker exits.

data/docs/DESIGN.md

@@ -3,9 +3,9 @@
 * Simplicity: Pitchfork is a traditional UNIX prefork web server.
   No threads are used at all, this makes applications easier to debug
   and fix.
-  
-* Resiliency: If something in goes catastrophically wrong and your application
-  is dead locked or somehow stuck, once the request timeout is reached the master
+
+* Resiliency: If something goes catastrophically wrong and your application
+  is dead locked or somehow stuck, once the request timeout is reached the monitor
   process will take care of sending `kill -9` to the affected worker and
   spawn a new one to replace it.
 
@@ -32,7 +32,7 @@
   optional, separate config_file may be used to modify supported
   configuration changes.
 
-* One master process spawns and reaps worker processes.
+* One monitor process spawns and reaps worker processes.
 
 * The number of worker processes should be scaled to the number of
   CPUs or memory you have. If you have an existing
@@ -75,12 +75,12 @@
   unportable event notification solutions for watching few
   file descriptors.
 
-* If the master process dies unexpectedly for any reason,
+* If the monitor process dies unexpectedly for any reason,
   workers will notice within :timeout/2 seconds and follow
-  the master to its death.
+  the monitor to its death.
 
 * There is never any explicit real-time dependency or communication
-  between the worker processes nor to the master process.
+  between the worker processes nor to the monitor process.
   Synchronization is handled entirely by the OS kernel and shared
   resources are never accessed by the worker when it is servicing
   a client.

data/docs/FORK_SAFETY.md

@@ -91,4 +91,7 @@ impact of discovering such bug.
 
 - Any gem binding with `libgobject`, such as the `gda` gem, likely aren't fork safe.
 
+- If you use `jemalloc`, [the version `5.2` is known to have a fork safety bug that can cause childs to lock up](https://github.com/jemalloc/jemalloc/issues/2019).
+  Make sure to upgrade to version `5.3`.
+
 No other gem is known to be incompatible for now, but if you find one, please open an issue to add it to the list.

data/docs/PHILOSOPHY.md

@@ -34,7 +34,7 @@ the right tool with the right configuration for the right job.
 
 ## Improved Performance Through Reverse Proxying
 
-By acting as a buffer to shield unicorn from slow I/O, a reverse proxy
+By acting as a buffer to shield `pitchfork` from slow I/O, a reverse proxy
 will inevitably incur overhead in the form of extra data copies.
 However, as I/O within a local network is fast (and faster still
 with local sockets), this overhead is negligible for the vast majority
@@ -45,7 +45,7 @@ A reverse proxy for `pitchfork` should meet the following requirements:
 
 1. It should fully buffer all HTTP requests (and large responses).
    Each request should be "corked" in the reverse proxy and sent
-   as fast as possible to the backend unicorn processes.  This is
+   as fast as possible to the backend `pitchfork` processes.  This is
    the most important feature to look for when choosing a
    reverse proxy for `pitchfork`.
 

data/docs/REFORKING.md

@@ -50,15 +50,15 @@ When you start `pitchfork` it forks a `mold` process which loads your applicatio
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 101       \_ pitchfork (gen:0) mold
 ```
 
-Once the `mold` is done loading, the `master` asks it to spawn the desired number of workers:
+Once the `mold` is done loading, the `monitor` asks it to spawn the desired number of workers:
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 101       \_ pitchfork (gen:0) mold
 102       \_ pitchfork (gen:0) worker[0]
 103       \_ pitchfork (gen:0) worker[1]
@@ -66,14 +66,14 @@ PID   COMMAND
 105       \_ pitchfork (gen:0) worker[3]
 ```
 
-As the diagram shows, while workers are forked from the mold, they become children of the master process.
+As the diagram shows, while workers are forked from the mold, they become children of the monitor process.
 We'll see how does that work [later](#forking-sibling-processes).
 
 When a reforking is triggered, one of the workers is selected to fork a new `mold`:
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 101       \_ pitchfork (gen:0) mold
 102       \_ pitchfork (gen:0) worker[0]
 103       \_ pitchfork (gen:0) worker[1]
@@ -82,7 +82,7 @@ PID   COMMAND
 105       \_ pitchfork (gen:1) mold
 ```
 
-Again, while the mold was forked from a worker, it becomes a child of the master process.
+Again, while the mold was forked from a worker, it becomes a child of the monitor process.
 We'll see how does that work [later](#forking-sibling-processes).
 
 When that new mold is ready, `pitchfork` terminates the old mold and starts a slow rollout of older workers and replace them with fresh workers
@@ -90,7 +90,7 @@ forked from the mold:
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 102       \_ pitchfork (gen:0) worker[0]
 103       \_ pitchfork (gen:0) worker[1]
 104       \_ pitchfork (gen:0) worker[2]
@@ -100,7 +100,7 @@ PID   COMMAND
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 103       \_ pitchfork (gen:0) worker[1]
 104       \_ pitchfork (gen:0) worker[2]
 105       \_ pitchfork (gen:0) worker[3]
@@ -117,15 +117,15 @@ a process tree such as:
 
 ```
 PID   COMMAND
-100   \_ pitchfork master
+100   \_ pitchfork monitor
 101       \_ pitchfork mold (gen:1)
 105          \_ pitchfork (gen:1) worker[0]
 ```
 
-However the `pitchfork` master process registers itself as a "child subreaper" via [`PR_SET_CHILD_SUBREAPER`](https://man7.org/linux/man-pages/man2/prctl.2.html).
-This means that any descendant process that is orphaned will be re-parented as a child of the master process rather than a child of the init process (pid 1).
+However the `pitchfork` monitor process registers itself as a "child subreaper" via [`PR_SET_CHILD_SUBREAPER`](https://man7.org/linux/man-pages/man2/prctl.2.html).
+This means that any descendant process that is orphaned will be re-parented as a child of the monitor process rather than a child of the init process (pid 1).
 
-With this in mind, the mold forks twice to create an orphaned process that will get re-attached to the master process,
+With this in mind, the mold forks twice to create an orphaned process that will get re-attached to the monitor process,
 effectively forking a sibling rather than a child. Similarly, workers do the same when forking new molds.
 This technique eases killing previous generations of molds and workers.
 

data/docs/SIGNALS.md

@@ -1,10 +1,10 @@
 ## Signal handling
 
-In general, signals need to only be sent to the master process. However,
+In general, signals need to only be sent to the monitor process. However,
 the signals Pitchfork uses internally to communicate with the worker
 processes are documented here as well.
 
-### Master Process
+### Monitor Process
 
 * `INT` - quick shutdown, kills all workers immediately
 
@@ -21,18 +21,17 @@ processes are documented here as well.
 
 ### Worker Processes
 
-Note: the master uses a pipe to signal workers
+Note: the monitor uses a pipe to signal workers
 instead of `kill(2)` for most cases.  Using signals still works and
 remains supported for external tools/libraries, however.
 
 Sending signals directly to the worker processes should not normally be
-needed.  If the master process is running, any exited worker will be
+needed.  If the monitor process is running, any exited worker will be
 automatically respawned.
 
 * `INT` - Quick shutdown, immediately exit.
-  The master process will respawn a worker to replace this one.
-  Immediate shutdown is still triggered using kill(2) and not the
-  internal pipe as of unicorn 4.8
+  The monitor process will respawn a worker to replace this one.
+  Immediate shutdown is triggered using kill(2).
 
 * `QUIT/TERM` - Gracefully exit after finishing the current request.
-  The master process will respawn a worker to replace this one.
+  The monitor process will respawn a worker to replace this one.

data/docs/TUNING.md

@@ -1,6 +1,6 @@
 # Tuning pitchfork
 
-unicorn performance is generally as good as a (mostly) Ruby web server
+Pitchfork performance is generally as good as a (mostly) Ruby web server
 can provide. Most often the performance bottleneck is in the web
 application running on Pitchfork rather than Pitchfork itself.
 
@@ -14,7 +14,7 @@ See Pitchfork::Configurator for details on the config file format.
 * `worker_processes` should be scaled to the number of processes your
   backend system(s) can support. DO NOT scale it to the number of
   external network clients your application expects to be serving.
-  unicorn is NOT for serving slow clients, that is the job of nginx.
+  Pitchfork is NOT for serving slow clients, that is the job of nginx.
 
 * `worker_processes` should be *at* *least* the number of CPU cores on
   a dedicated server (unless you do not have enough memory).
@@ -29,7 +29,7 @@ See Pitchfork::Configurator for details on the config file format.
 
 * Bigger is better. The more `worker_processes` you run, the more you'll
   benefit from Copy-on-Write. If your application use 1GiB of memory after boot,
-  running `10` worker process, the relative memory usage per worker will only be
+  running `10` worker processes, the relative memory usage per worker will only be
   `~100MiB`, whereas if you only run `5` worker processes, there relative usage will be
   `~200MiB`.
   So if you can chose your hardware, it's preferable to use a smaller number

data/examples/nginx.conf

@@ -71,7 +71,7 @@ http {
   # this can be any application server, not just unicorn
   upstream app_server {
     # fail_timeout=0 means we always retry an upstream even if it failed
-    # to return a good HTTP response (in case the unicorn master nukes a
+    # to return a good HTTP response (in case the unicorn monitor nukes a
     # single worker for timing out).
 
     # for UNIX domain socket setups:

data/examples/pitchfork.conf.rb

@@ -26,7 +26,7 @@ run_once = true
 
 after_mold_fork do |server, mold|
   # Occasionally, it may be necessary to run non-idempotent code in the
-  # master before forking.  Keep in mind the above disconnect! example
+  # monitor before forking.  Keep in mind the above disconnect! example
   # is idempotent and does not need a guard.
   if run_once
     # do_something_once_here ...

data/ext/pitchfork_http/c_util.h

@@ -1,6 +1,6 @@
 /*
  * Generic C functions and macros go here, there are no dependencies
- * on Unicorn internal structures or the Ruby C API in here.
+ * on Pitchfork internal structures or the Ruby C API in here.
  */
 
 #ifndef UH_util_h
@@ -60,7 +60,7 @@ static int hexchar2int(int xdigit)
   if (xdigit >= 'a' && xdigit <= 'f')
     return xdigit - 'a' + 10;
 
-  /* Ragel already does runtime range checking for us in Unicorn: */
+  /* Ragel already does runtime range checking for us in Pitchfork: */
   assert(xdigit >= '0' && xdigit <= '9' && "invalid digit character");
 
   return xdigit - '0';

data/ext/pitchfork_http/epollexclusive.h

@@ -1,11 +1,11 @@
 /*
- * This is only intended for use inside a unicorn worker, nowhere else.
+ * This is only intended for use inside a pitchfork worker, nowhere else.
  * EPOLLEXCLUSIVE somewhat mitigates the thundering herd problem for
  * mostly idle processes since we can't use blocking accept4.
  * This is NOT intended for use with multi-threaded servers, nor
  * single-threaded multi-client ("C10K") servers or anything advanced
  * like that.  This use of epoll is only appropriate for a primitive,
- * single-client, single-threaded servers like unicorn that need to
+ * single-client, single-threaded servers like pitchfork that need to
  * support SIGKILL timeouts and parent death detection.
  */
 #if defined(HAVE_EPOLL_CREATE1)

data/lib/pitchfork/children.rb

@@ -2,7 +2,7 @@
 # frozen_string_literal: true
 
 module Pitchfork
-  # This class keep tracks of the state of all the master children.
+  # This class keep tracks of the state of all the monitor children.
   class Children
     attr_reader :mold, :service
     attr_accessor :last_generation