Date | Commit message (Collapse) |
|
It's in the JoinThreads module now
|
|
They're not bad with slow clients a previously thought.
|
|
acceptor thread pools could use some work, still
|
|
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.
|
|
No point in waking up when our ticker runs in a separate
thread.
|
|
Hopefully this will make our code easier to follow.
|
|
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.
|
|
We may use a blocking accept() loop if there is
only a single listener. In that case threads may
not be able to exit if a SIGQUIT is received, so
force them to run when joining.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
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).
|
|
|
|
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.
|
|
Like the rest of the concurrency models. This gives us
more flexibility in case a process-wide blocking operation
started during an "unlucky" period when the join timeout
was about to expire.
|
|
The problem is unconfirmed at the moment, but I've long
anticipated it. I just need to remember the next time I
log into a monster machine.
|
|
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.
|
|
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.
|
|
|
|
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
|
|
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|