Date | Commit message (Collapse) |
|
They're not bad with slow clients a previously thought.
|
|
Run under 1.9.3dev
|
|
We noticed a few more things that could be cleaned
up after the last commit.
|
|
Code organization is hard :<
|
|
Rack::Utils::HeaderHash is still very expensive in Rack 1.2,
especially for simple things that we want to run as fast as
possible with minimal interference. HeaderHash is unnecessary
for most requests that do not send Content-Range in responses.
|
|
Hopefully this will make our code easier to follow.
|
|
This lets Rainbows! yield the current worker process
when busy in the hopes another worker will pick up the
slack. We can also override this for the single worker
process case later if people care enough.
|
|
It removes the burden of byte slicing and setting file
descriptor flags. In some cases, we can remove unnecessary
peeraddr calls, too.
|
|
Trying to avoid adding singleton methods since it's too easily
accessible by the public and not needed by the general public.
This also allows us (or just Zbatery) to more easily add support
systems without FD_CLOEXEC or fcntl, and also to optimize
away a fcntl call for systems that inherit FD_CLOEXEC.
|
|
Since we suck at building websites, we just rely on RDoc as a
website builder. And since Rainbows! is an application server
(and not a programming library), our internal API should be of
little interest to end users.
Anybody interested in Rainbows! (or any other project) internals
should be reading the source.
|
|
|
|
Under all MRI 1.8, a blocking Socket#accept Ruby method (needs
to[1]) translate to a non-blocking accept(2) system call that may
wake up threads/processes unnecessarily. Unfortunately, we
failed to trap and ignore EAGAIN in those cases.
This issue did not affect Ruby 1.9 running under modern Linux
kernels where a _blocking_ accept(2) system call is not (easily,
at least) susceptible to spurious wakeups. Non-Linux systems
running Ruby 1.9 may be affected.
[1] - using a blocking accept(2) on a shared socket with
green threads is dangerous, as noted in
commit ee7fe220ccbc991e1e7cbe982caf48e3303274c7
(and commit 451ca6997b4f298b436605b7f0af75f369320425)
|
|
It's a tad faster for non-keepalive connections and should do
better on large SMP machines with many workers AND threads.
That means the ActorSpawn model in Rubinius is nothing more than
ThreadSpawn underneath (for now).
|
|
|
|
Not sure what drugs the person that wrote it was on at the
time.
|
|
Make sure app errors get logged correctly, and we no longer
return a 500 response when a client EOFs the write end (but not
the read end) of a connection.
|
|
It turns out neither the EventMachine and Rev classes
checked for master death in its heartbeat mechanism.
Since we managed to forget the same thing twice, we
now have a test case for it and also centralized the
code to remove duplication.
|
|
We use the "G" global constant from the Rev model everywhere
to simplify things a little.
Test cases are more consistent now, too.
|
|
It's more fool-proof this way and prevents us from using
idiotic/non-obvious concurrency model names.
|
|
I need better tests for graceful shutdown...
|
|
|
|
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.
|
|
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).
|
|
In Unicorn by HttpServer#init_worker_process
|
|
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.
|
|
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 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.
|