| Date | Commit message (Collapse) |
|---|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
Some async apps rely on more than just "async.callback" and
make full use of Deferrables provided by the EM::Deferrable
module. Thanks to James Tucker for bringing this to our
attention.
|
|
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)
|
|
We'll export this across the board to all Rack applications
to sleep with. This provides the optimum method of sleeping
regardless of the concurrency model you choose. This method
is still highly not recommended for pure event-driven models
like Rev or EventMachine (but the threaded/fiber/actor-based
variants are fine).
|
|
|
|
This is like the traditional FiberSpawn, but more scalable (but
not necessarily faster) as it can use epoll or kqueue.
|
|
There's a good chunk of tests that fail with this, still.
Worse, I haven't been able to figure out what's wrong since
it looks like it would involve looking at C++ code...
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
If we logged "ERROR", we should know about it.
|
|
|
|
Some people fork processes, so it avoid hanging a connection
open because of that...
|
|
One bad thing to defaulting to ksh93 for my tests during
development, small cleanups while we're at it, too for
extra checks
|
|
The test itself already exits immediately if it's
running an incompatible concurrency model, so avoid
having redundant logic in the GNUmakefile.
|
|
|
|
This lets us make further tests for compatibility without
dirtying our working tree.
|
|
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.
|
|
Both FiberSpawn and FiberPool share similar main loops, the
only difference being the handling of connection acceptance.
So move the scheduler into it's own function for consistency.
We'll also correctly implement keepalive timeout so clients
get disconnected at the right time.
|
|
This enables the safe use of Rainbows::AppPool with all
concurrency models, not just threaded ones. AppPool is now
effective with *all* Fiber-based concurrency models including
Revactor (and of course the new Fiber{Pool,Spawn} ones).
|
|
It works exactly like Actor.sleep and similar to Kernel.sleep
(no way to sleep indefinitely), but is compatible with the
IO.select-based Fiber scheduler we run. This method only works
within the context of a Rainbows! application dispatch.
|
|
This is another Fiber-based concurrency model that can exploit
a streaming "rack.input" for clients. Spawning Fibers seems
pretty fast, but maybe there are apps that will benefit from
this.
|
|
This one seems a easy to get working and supports everything we
need to support from the server perspective. Apps will need
modified drivers, but it doesn't seem too hard to add
more/better support for wrapping IO objects with Fiber::IO.
|
|
Exposing a synchronous interface is too complicated for too
little gain. Given the following factors:
* basic ThreadSpawn performs admirably under REE 1.8
* both ThreadSpawn and Revactor work well under 1.9
* few applications/requests actually need a streaming "rack.input"
We've decided its not worth the effort to attempt to support
streaming rack.input at the moment. Instead, the new
RevThreadSpawn model performs much better for most applications
under Ruby 1.9
|
|
And change the default to 2 seconds, most clients can
render the page and load all URLs within 2 seconds.
|
|
Make sure any aborted/broken clients don't screw up
our connection accounting.
|
|
Avoid the chances of misfiring when waiting on the master
process to start in case something bad happens or we're
sharing the FIFO for other purposes.
|
|
It seems possible to have a race condition here with
the FIFO being overloaded for both start detection
and blocking. Since SIGSTOP is unavoidable, just use
that instead and sleep immediately afterwards in case
SIGSTOP is not processed in time.
|
|
Counting worker connections is easy-to-forget when implementing
new concurrency models and forgetting to do it means new clients
cannot be accepted. Fortunately some concurrency models tend
to do it for us.
|
|
When reading 4K chunks, performance is dismal under 1.8
|
|
In Unicorn, the master reopens logs before the workers do in
case the workers die while reopening logs. But for our test
cases (and real-world usage) we need to ensure the workers have
reopened logs as well.
|
|
|
|
Explicitly requested short reads may cause too much data to be
returned, which would be bad and potentially break the
application. We need to ensure proper IO#readpartial-like
semantics in both of these models.
|
|
Seems to pass all tests, but that may only mean our
test cases are lacking...
|
|
env['rack.input']read(length) may return nil zero-sized inputs
|
|
sha1sum(1) is only common GNU systems, and it may be installed
as gsha1sum on *BSDs. We'll also try using the openssl sha1
implementation, too. And finally, we'll provide our own Ruby
sha1sum.rb implementation as a last resort.
We go to great lengths to avoid our own Ruby version because we
want to avoid putting too much trust in ourselves, our Ruby
skills, and even the Ruby implementations. This is especially
with regard to our knowledge and correct usage of Ruby 1.9
encoding support. It would actually be *easier* to only use
sha1sum.rb and call it a day. We just choose to support
SHA1 implementations provided by third parties if possible.
Performance is not a factor since sha1sum.rb performance is very
close to the C implementations.
|
|
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.
|
|
It's also more portable since "+" isn't portable on
FreeBSD.
|
|
Add tests to ensure we set it correctly and it gets
passed down to the app.
|
|
This test lead to two separate bugfixes in Unicorn, one in the
HttpParser and the other in TeeInput. Ironically, this test was
spawned from what I initially thought was a bug in the EvCore
module used by Rev and EventMachine, but there was no bug in
EvCore...
|
|
|
|
We've worked around trigger happy timeouts in the
master since we track the timeout at a lower resolution
here.
|
|
We need to resort to SIGSTOP to block off processes entirely
since 1.9 uses native threads.
|
|
It's not portable to FreeBSD 7.2 /bin/sh
|
|
This module will be reused in upcoming Rev-derived concurrency
models.
|
|
Also new are added basic HTTP tests for UNIX domain socket
handling (for all models, now, of course).
|
|
|
|
Using a "+" suffix alone was not enough protection since we use
evil recursive makes and can't share dependency info with parent
makes. While this could be done more efficiently (even with
recursive make), but it'd be harder to maintain. So we generate
the dependencies later to and sacrifice efficiency on the
initial run (but rarely/never again).
|
|
This makes it easier to figure out why tests are failing
for people that forget to read t/README
|
|
|
|
Even though our tests do an extra check, it's faster to
not unnecessarily invoke the check in the first place.
|