| Date | Commit message (Collapse) |
|---|
|
Enabling thread-safe or thread-aware code paths in applications
may even be dangerous in some cases and cause deadlocks in code
that otherwise does not expect threads. This is especially true
of the Revactor case where being a "drop-in" replacement for IO
routines is dangerous if a mutex is held while an Actor performs
a "blocking" I/O operation.
Basically start to assume that anybody writing an app using
Rev or Revactor already takes Rev/Revactor concurrency into
account and won't need the rack.multithread flag set to do
special things.
|
|
There is no TeeInput (streaming request body) support, yet,
as that does not seem fun nor easy to do (or even possible
without using Threads or Fibers or something to save/restore
the stack...)
|
|
Just like in Unicorn...
|
|
They were completely broken in the refactoring :x
|
|
|
|
The process-based heartbeat continues, but we no longer time
threads out just because a client is idle for any reason (for
now).
|
|
Avoid overloading the "alive" variable here and wakeup less
frequently as well to do the fchmod.
|
|
We'll finish processing the current request and
set the "Connection: close" header if possible.
|
|
In Unicorn by HttpServer#init_worker_process
|
|
|
|
Once our listeners get closed, we're as good as
dead so we should exit to avoid spinning.
|
|
This can be common across everything
|
|
Avoid potential race conditions with signal handlers, this makes
exits cleaner since the LISTENERS array will get map!-ed to nils
in the :QUIT signal handler.
|
|
It'll be easier to maintain a common language for logging
and debugging.
|
|
We log thread destruction times now and also make a best-effort
to avoid race conditions on threads that just finished.
|
|
Something is probably wrong with the OS if it does,
so make sure it gets logged and hopefully reported.
|
|
Bad stuff happens, even in our own code because sometimes
we don't know what we're doing. So log it so we'll know to
fix it and let life go on...
|
|
EAGAIN is common on accept_nonblock with multiple processes
sharing the same listen descriptors.
oops :x
|
|
This is for compatibility with OpenBSD as reported
by Jeremy Evans for Unicorn.
|
|
|
|
Fixed Ruby 1.8 support (and all 1.9 systems without Revactor).
Process-wide timeout handling for the ThreadSpawn concurrency
model should now work properly. Small cleanups everywhere.
Eric Wong (16):
Rakefile: add publish_news target
Fix NEWS generation on single-paragraph tag messages
README: move RDoc links down to fix gem description
README: add install instructions
summary: s/slow apps/sleepy apps/g
Avoid naming names in LICENSE/README files
rainbows/base: cleanup constant include
tests: quiet down bin installation
Add top-level "test" target for make
local.mk.sample: sync to my current version
tests: allow "make V=2" to set TEST_OPTS += -x
cleanup temporary file usage in tests
local.mk.sample: fix revactor dependency
Thread* models: cleanup timeout management
thread_spawn: fix timeout leading to worker death
less error-prone timeouts for Thread models
|
|
Avoid calling chmod on "false" leading to NoMethodError
and rely entirely on LISTENERS.first being valid.
|
|
|
|
Ensure we reset the per-thread time Thread.current[:t] with each
connection so we don't timeout long-lived connections.
|
|
This was breaking badly under 1.8 since Revactor couldn't be
included (the constant is listed once it is declared as an
autoload).
|
|
Not using the Unicorn version number with this
since it's not remotely close to Unicorn in stability.
|
|
|
|
Only inject this method into Unicorn::Configurator to avoid
polluting the namespace.
|
|
Various concurrency models work and scale differently, pick
counts that make a reasonable amount of sense...
|
|
This is somewhat like the original model found in Mongrel,
except we refuse to accept() connections unless we have slots
available. Even though we support multiple listen sockets, we
only accept() synchronously to simplify processing and to avoid
having to synchronize ThreadGroup management.
|
|
It's usually a bad sign if we have unhandled exceptions in
the listener loops, so we'll exit just in case.
|
|
While we're at it, make it properly 100% message-driven so
there's no more busy-waiting and polling for dead actors, No we
just wait for client actors to die off and resume listener
actors if they stopped accepting.
|
|
Also add notes about development things and the configuration
language which uses "Rainbows!". Calling ourselves "Rainbows!"
will help us be taken even more seriously than if the project
were just called "Rainbows"
|
|
Revactor may be gaining support for UNIX domain socket listeners
soon, so factor out revactorize_listeners into its own method
that can conditionally handle UNIX domain sockets if our
Revactor version supports it.
Patch for Revactor submitted here:
http://rubyforge.org/pipermail/revactor-talk/2009-October/000035.html
|
|
:Base is default (along with the implied worker_connections=1).
This disallows nil for worker_connections, and makes.
|
|
So are Thread#terminate! and Thread#exit!, so we use
Thread#kill instead.
|
|
They're similar enough (especially as far as the constants go)
and allows a :Base to be used which basically acts like plain
Unicorn but with HTTP keepalive + pipelining support
|
|
Patch submitted upstream:
http://rubyforge.org/pipermail/revactor-talk/2009-October/000034.html
|
|
This allows the server to be configured by doing something like
this inside an existing Unicorn configuration file:
Rainbows! do
use :Revactor
worker_connections 50
end
This should make it obvious we're using Rainbows-only features.
|
|
I didn't remember extend when this was originally implemented.
|
|
This should make it easier to maintain/read configs that
are Rainbows-specific
|
|
|
|
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|