Date | Commit message (Collapse) |
|
It's usually given as a block, so Ruby won't care about arity there.
Users will get the worker ID number as the first arg, making it
possible to isolate some things to certain processes (e.g. for A/B
testing).
|
|
It was totally unnecessary and just made things hard-to-follow.
|
|
Users of other web servers may be surprised there is no recommended
way to have a new instance of yahns inherit from another web server.
|
|
This allows modifying the command-line (as an array) passed to
Kernel#exec, as well as running anything necessary.
|
|
The default value was incorrect, also expand on common reasons
why it should be tweaked.
|
|
Otherwise, the server may stay running forever if a client chooses
to stay forever (and there is no FD pressure).
|
|
With a GVL-free Ruby implementation, the following situation
may occur as FDs are recycled frequently with 3 threads
running:
expiry | normal | acceptor
-----------------------+-----------+----------------------
yahns_expire(fd).enter | |
| close(fd) |
| | accept().return => fd
shutdown(fd) - WRONG | |
-----------------------+-----------+----------------------
So we must prevent expiry from running while another thread
is closing, otherwise there is a small chance a lack of
lock inside the Ruby implementation itself can lead to a
mis-issued close() to a fast-recycled FD.
|
|
We need to account for the directory change since yahns may lazily
require some files. GTL is also not needed inside a child process.
|
|
Different instances/ports of apps may want to point error
output elsewhere.
|
|
Hopefully saves us from running out of FDs when doing parallel
tests.
|
|
This is often forgotten, and we need to make a tweak to the
coverage generator to dump correctly.
|
|
There were some old Ruby versions where there was a minor
difference, but they're identical from 1.9 onwards and this
has lower cognitive overhead.
|
|
These are implemented trivially and based on working code, but test
them anyways.
|
|
The rest of the config handling spews ArgumentError when
a user sets something bad...
|
|
This saves about 200 bytes of unswappable kernel memory,
so it might matter for systems with many connections
when hijacking.
|
|
This should prevent us from introducing bugs into some otherwise
rarely-tested code.
|
|
Not all servers may have options set, and we still need to set
the default backlog.
|
|
Oops, this was only noticed when inheriting a descriptor
we want to close.
|
|
We may inherit descriptors we never spawned threads for,
so account for @thrs not being defined, yet.
|
|
This is probably not needed and just adds contention, but it makes
experimenting easier.
While we're at it, validate minimum values of for sndbuf/rcvbuf
along with this new threads value, too.
|
|
This allows us to avoid some FD leakage and waste of
memory allocations.
|
|
We need to be able to resume hijacking if gigantic HTTP headers are
buffered on the response.
|
|
While we're at it, add some additional tests for input handling.
|
|
This should be compatible with the "gem-man" command.
|
|
We may also return HTTP 408 errors in this case.
|
|
8K is the default for nginx, too. This prevents Ruby/malloc from
getting too fragmented with large buffers and being unable to release
memory back to the OS.
While we're at it, update the documentation to reflect we use this
parameter to control read(2) sizes, too.
|
|
Negative ratio makes little sense and there's no reason to
allow it.
|
|
Unfortunately, my eyes are more-or-less trained to ignore
documentation when I edit code.
|
|
working_directory affects the whole process, so it must be
called at the top-level and not allowed inside blocks.
|
|
In case we (and Linux) supports other values in the future,
we can update it then. Until now, ensure users only set
true or false for this option.
commit 03580a19afe5ce76323a7366b92243a94d445de1 in unicorn
|
|
This was documented (incorrectly) and not implemented for either
the master/worker or single process cases. Implement and test
all (with mocks, so not fully-tested).
|
|
This should make these definitions easier-to-find with grep(1)
|
|
This should hopefully make yahns more appealing and easier-to-use.
|
|
naming new (global) queues should be done outside of app
contexts. Private, per-app queues should be anonymous to
avoid confusion.
|
|
We use QueueQuitter, nowadays, so we no longer rely on cross-thread
close to destroy a running thread blocked on epoll_wait.
|
|
We do not want users to use the default queue unless an app
context requires it. We also do not want to spin up the default
queue unless we are sure we have app contexts using it (and
not private/anonymous queues).
|
|
We'll leave setting RACK_ENV and RAILS_ENV to be the responsibility
of the user. RACK_ENV makes little sense here since we do not
do anything with it, and a global environment variable makes hosting
different apps unpredictable.
|
|
We will have no public API outside the config file. Since this is a
*nix-only (and possibly Linux-only, even), manpages are
language-agnostic and easier for users (sysadmins) who may not be
familiar with Ruby/RDoc. All *nix-based Rubyists I've encountered
are familiar with manpages, already.
We won't have to worry about users being confused by our docs strewn
across frames/CSS/JS-ridden sites like rdoc.info, either :)
|
|
This allows users to start an independent instance of unicorn on
a the same port as a running unicorn (as long as both instances
use :reuseport).
ref: https://lwn.net/Articles/542629/
|
|
This should make things a little easier-to-follow and possibly
improve method cache hit rates for servers with multiple acceptors.
|
|
This should help prevent some errors from popping up.
Obviously, we cannot spend too long doing this inside
a worker thread.
|
|
We may end up buffering on headers and hitting EMFILE/ENFILE this
way, too. We need to figure out a way to recover from this.
|
|
We'll hit SIGCHLD if our reexec process fails on us, so the
non-MP server must handle it, too. We discovered this bug
while porting the PID file renaming changes from unicorn.
|
|
This reduces the amount of code we have in our tests to
improve maintainability.
|
|
The write buffer may block on a single write and immediately
become unblocked afterwards. We need to account for this odd
corner case when serving static files; because clients can
trigger strange corner cases like this.
|
|
The tiny responses for check_client_connection and "100-Continue"
responses may occasionally fail with EAGAIN. We must be prepared
for those corner cases and buffer the output appropriately. We can
safely use a string for buffering here (for once(!)), since the
buffer sizes are bounded and known at buffer time, unlike the
response headers/bodies sent by the Rack application.
|
|
It was getting too large to be manageable and rarer paths for
bodies/trailers can be hoisted out.
|
|
|
|
We need to prevent FD leakage on Ruby 1.9.3
|
|
pipes and eventfd are always writable after creation, thus
there's no need to trigger it and watch for readability.
This saves us some code in the Linux case (and we currently
only support GNU/Linux).
|