| Date | Commit message (Collapse) |
|---|
|
Based on activity in <git://github.com/eventmachine/eventmachine>,
EventMachine seems to be maintained, again, so resume testing our
integration tests.
|
|
Apparently GNU make parses that strangely and mangles it for the
shell...
|
|
This will allow me to test for unintentional breakage in 2.2.0.
Part of the reason for putting this project on maintenance mode
is because many of the libraries we depend on have not kept up
with the latest changes to Ruby. So we will disable many tests
for 2.2+ to ensure the core parts remain working.
|
|
EM 1.0.3 got released and seems to work under Ruby 2.1,
so re-enable EM and NeverBlock tests again.
|
|
EventMachine/NeverBlock currently do not build on Ruby 2.0.0
|
|
The missing random_blob dependency was causing the following
to fail on a fresh clone:
make -C t ThreadPool.t0005-large-file-response.sh
|
|
This doesn't use Rainbows::Base so we have no keepalive support
at all. This could eventually be an option for streaming
applications.
|
|
This is probably friendlier on server resources in the worst
case than XEpollThreadSpawn but may perform worse in the client
client-visible way, too.
|
|
Whee! This is going to be awesome.
|
|
Revactor doesn't seem to work under 1.9.3dev, and Revactor is
dead upstream.
|
|
It's too long especially since XEpollThreadPool is planned :>
|
|
epoll is Linux-only right now. kqueue probably isn't worth
supporting directly (and even direct epoll support is debatable
given the current GVL situation)
|
|
Edge-triggered epoll concurrency model with blocking accept() in
a (hopefully) native thread. This is recommended over Epoll for
Ruby 1.9 users as it can workaround accept()-scalability issues
on multicore machines.
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
Cool.io is the new name for Rev. We'll continue to support Rev
until Cool.io breaks backwards compatibility. Rev may not be
supported if Cool.io is.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
We may want to try some external libraries for some tests
via RUBYLIB/RUBYOPT while doing development.
|
|
It hits 100% CPU usage and Rev's 1.8 support when mixed
with threads is currently suboptimal. Unfortunately
our tests can not check for 100% CPU usage, so I had to
*gasp* confirm it by actually starting an app :x
This appears to be a fixable bug in Rev, however, and
we'll try to fix it as soon as we have time.
|
|
|
|
Rubinius still has a few issues that prevent 100% support,
but it basically works if log rotation or USR2 upgrades aren't
required. Tickets for all known issues for Rubinius have
been filed on the project's issue tracker.
* rbx does not support -i/-p yet, so rely on MRI for that
* "io/nonblock" is missing
* avoiding any optional Gems for now (EM, Rev, etc..)
|
|
It was missing dependencies on the first run
|
|
We don't need tmp/ in our top level directory
|
|
It's useful given all the Gems we support but don't have hard
installation dependencies on.
|
|
|
|
This is based on an idea I originally had for Unicorn but never
implemented in Unicorn since the benefits were unproven and the
risks were too high.
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
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.
|
|
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
|
|
Seems to pass all tests, but that may only mean our
test cases are lacking...
|
|
It's not portable to FreeBSD 7.2 /bin/sh
|
|
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.
|
|
Use a bigger random_blob and run GC before checking RSS
|
|
This means Rainbows::DevFdBody async responses and large
file streaming without slurping.
This is only with eventmachine 0.12.8, it looks like 0.12.10
changes the attach/watch API...
|
|
log reopens, graceful shutdown, HTTP error responses
should all be working now.
|
|
This makes it easier to filter functionality by model.
|
|
This will make it easier to enable and manage tests for new
concurrency models.
|
|
Everything passes, and "set -e" prevents us from
making any stupid mistakes...
|
|
It's more common form for externally-visible/modifiable
variables in Makefiles and shell scripts.
|