Date | Commit message (Collapse) |
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
This is also our website, so we need to document the new
Cool.io-based concurrency options for users and point
existing Rev* users to it.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
It is a common base so we can share documentation tasks
more easily with Unicorn and it ensures our RDoc no longer
has JavaScript in it!
|
|
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.
|
|
I still have a hard time keeping track of what's capable of
what.
|
|
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
working_directory and Worker#user got added over time, so
recommending Dir.chdir and Process::UID.change_privilege
is bad.
|
|
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).
|
|
|
|
|
|
manpage was blatantly copied from the Unicorn one but headers
were never updated.
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
|
|
Guess I'll have to make the Revactor model work with that.
|
|
|
|
Patches submitted to rev-talk, awaiting feedback and
hopefully a new release.
|
|
|
|
This will hopefully make many things clearer about the project.
|
|
|
|
No tests yet, but the old "gossamer" and "rainbows" branches
seem to be basically working.
|