| Date | Commit message (Collapse) |
|---|
|
This release introduces compatibility with Sunshowers, a library
for Web Sockets, see http://rainbows.rubyforge.org/sunshowers
for more information. Several small cleanups and fixes.
Eric Wong (20):
add RevThreadPool to README
rev: do not initialize a Rev::Loop in master process
rainbows.1: update headers
do not log IOError raised during app processing
move "async.callback" constant to EvCore
larger thread pool default sizes ({Rev,}ThreadPool)
ev_core: no need to explicitly close TmpIOs
EventMachine: allow usage as a base class
NeverBlock: resync with recent our EM-related expansion
RevThread*: move warning message to a saner place
EventMachineDefer: preliminary (and) broken version
TODO: add EM Deferrables
RevThread*: remove needless nil assignment
README: HTML5 Web Sockets may not be supported, yet...
env["hack.io"] for Fiber*, Revactor, Thread* models
EventMachineDefer is experimental
README: add Sunshowers reference
Rakefile: resync with Unicorn
doc/comparison: add Web Sockets to comparison
README updates
|
|
|
|
|
|
* cleanup NEWS.atom.xml feed
* add freshmeat update task
|
|
|
|
Not enough time or interest at the moment to get this
fully working...
|
|
This exposes a client IO object directly to the underlying
application.
|
|
|
|
We no longer explicitly close @input
|
|
EM.defer and EM Deferrables aren't the same thing,
guess we'll have to figure out how to support both.
|
|
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...
|
|
Don't expect RevThreadPool to work with Rev <= 0.3.1, either.
|
|
The last change to our EventMachine support code broke
our (lightly-tested) NeverBlock support badly.
|
|
We'll be adding EventMachine-based concurrency models.
|
|
Just let the GC deal with it
|
|
This matches what EM sets for its built-in thread pool
|
|
Rev/Packet-based models may support it in the future
|
|
A client disconnect could possibly trigger IOError on
close whereas EOFError does not occur.
|
|
manpage was blatantly copied from the Unicorn one but headers
were never updated.
|
|
It may make it harder to switch between concurrency models with
SIGHUP this way...
|
|
|
|
This release fixes a memory leak in our existing Revactor
concurrency model. A new RevThreadPool concurrency model has
been added as well as small cleaups to exit handling in workers.
|
|
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
We now correctly exit!(2) if our master can't kill us.
|
|
This model has basically been rewritten to avoid unbounded
memory growth (slow without keepalive) due to listeners
not properly handling :*_closed messages.
Performance is much more stable as a result, too.
|
|
Just die naturally here if threads don't die on
their own.
|
|
keepalive_timeout (default: 2 seconds) is now supported to
disconnect idle connections. Several new concurrency models
added include: NeverBlock, FiberSpawn and FiberPool; all of
which have only been lightly tested. RevThreadSpawn loses
streaming input support to become simpler and faster for the
general cases. AppPool middleware is now compatible with all
Fiber-based models including Revactor and NeverBlock.
A new document gives a summary of all the options we give you:
http://rainbows.rubyforge.org/Summary.html
If you're using any of the Rev-based concurrency models, the
latest iobuffer (0.1.3) gem will improve performance. Also,
RevThreadSpawn should become usable under MRI 1.8 with the next
release of Rev (0.3.2).
|
|
Shells already expand '~' before the executables see it, and
relative paths inside symlinks can get set incorrectly to the
actual directory name, and not the (usually desired) symlink
name for things like Capistrano.
Since our paths are now unexpanded, we must now check the
"working_directory" directive and raise an error if the user
specifies the config file in a way that makes the config file
unreloadable.
|
|
iobuffer 0.1.3 already sets this.
|
|
|
|
|
|
|
|
RDoc likes them for some reason
|
|
|
|
Eventually we hope to be able to accept arguments like
the way Rack handlers do it:
use :Foo, :bool1, :bool2, :option => value
|
|
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).
|
|
|
|
I so wish it used Fibers/green-threads underneath instead.
|
|
|
|
If we logged "ERROR", we should know about it.
|
|
|
|
Some people fork processes, so it avoid hanging a connection
open because of that...
|
|
|
|
Broken in 145185b76dafebe5574e6a3eefd3276555c72016
|
|
Rubinius Actor specs seem a bit lacking at the moment.
If we find time, we'll fix them, otherwise we'll let
somebody else do it.
|
|
It seems to basically work, this is based heavily on the
Revactor one...
|
|
Guess I'll have to make the Revactor model work with that.
|
|
Not sure what drugs the person that wrote it was on at the
time.
|
|
It can noticeably improve performance if available.
ref: http://rubyforge.org/pipermail/rev-talk/2009-November/000116.html
|