Date | Commit message (Collapse) |
|
It's better under 1.9.3 (sleepy_penguin 3.0.1 was bogus)
|
|
It's better under 1.9.3
|
|
|
|
It should hopefully give this more visibility even though it's
an internal feature.
|
|
We need to trigger a recv() to uncork the response.
This won't affect fairness (much) since all recv()s
are non-blocking and a successful header parse will
put us in the back of the queue.
|
|
Some folks use them.
|
|
We can support it fully for a subset of concurrency models where
we have full control over buffering and HTTP/1.1 keepalive
clients.
|
|
This will only be supported for certain concurency models, but
it's probably good enough.
|
|
Since it's cheap to maintain keepalive clients with EM, we need
a way of disconnecting them in a timely fashion on rare SIGQUIT
events.
|
|
This should enable Kgio "autopush" support for ThreadSpawn,
ThreadPool, XEpollThreadSpawn, and XEpollThreadPool.
(still needs tests)
|
|
In concurrency models long keepalive times are cheap (and thus
more likely to be used), this allows Rainbows! to gracefully
shut down more quickly.
|
|
There's less logic in the server this way and easier
to potentially share code this way.
|
|
io_splice 4.1.1 works around issues with socket
buffers filling up pipe buffers on blocking splice.
See http://lkml.org/lkml/2009/1/13/478 for a better
explanation.
|
|
* improved documentation all around, suggestions/comments to further
improve documentation is greatly welcome at: rainbows-talk@rubyforge.org
* added GPLv3 option to the license (now (Ruby|GPLv2|GPLv3), though
Unicorn is still (Ruby|GPLv2) for now)
* added client_header_buffer_size config directive (default 1K)
* small default header buffer size (16K => 1K) to reduce memory usage,
Rails apps with cookie sessions may want to increase this (~2K)
* all concurrency models default to 50 connections per process
* all concurrency models with a secondary :pool_size parameter also
default to 50 (threads/fibers/whatever)
* RLIMIT_NOFILE and RLIMIT_NPROC are automatically increased if needed
* Rainbows::ThreadTimeout middleware rewritten, still not recommended,
lazy people should be using Unicorn anyways :)
* Several experimental Linux-only edge-triggered epoll options:
XEpollThreadSpawn, XEpollThreadPool, XEpoll, and Epoll.
The latter two were in previous releases but never announced.
These require the "sleepy_penguin", "raindrops", and "sendfile" RubyGems
=== Deprecations
* Rainbows::Fiber::IO* APIs all deprecated, Rainbows! will avoid
having any concurrency model-specific APIs in the future and
also avoid introducing new APIs for applications.
* Fiber-based concurrency models are no longer recommended, they're
too fragile for most apps, use at your own risk (they'll continue to
be supported, however). Linux NPTL + Ruby 1.9 is pretty lightweight
and will be even lighter in Ruby 1.9.3 if you're careful with stack
usage in your C extensions.
|
|
I can't wait until I stop supporting Ruby 1.8
|
|
Hopefully makes things easier to try out.
|
|
The only supported method is Rainbows.sleep in here
|
|
Only needed for Ruby 1.9
|
|
Just close the epoll descriptor, since the sleepy_penguin
epoll_wait wrapper may not return EINTR in the future.
|
|
This makes things easier to maintain as we add more concurrency
options.
|
|
This allows using IO::Splice.copy_stream from the "io_splice"
RubyGem on recent Linux systems. This also allows users to
disable copy_stream usage entirely and use traditional
response_body.each calls which are compatible with all Rack
servers (to workaround bugs in IO.copy_stream under 1.9.2-p180).
|
|
Finally, we have all methods in configurator and it's
much easier to document!
|
|
It can't be used as middleware for fully-buffering concurrency
models.
|
|
GPLv2 and Ruby-specific terms remain intact, but this means
we can be combined and redistributed with GPLv3-only software
(once Unicorn has GPLv3 added to its license).
|
|
There's actually no reason we can't have these methods
in Rainbows::Configurator where it's easier to document
nowadays.
|
|
CoolioThreadPool has had it supported forever, but
only NeverBlock had it documented.
|
|
Some things were never going to get done due to lack of interest
from users.
|
|
Clearly users need to know about more options
|
|
It's good to describe what they're useful for.
|
|
It's an internal implementation detail.
|
|
speling ficks and less confusing #initialize documentation
|
|
We're now able to configure the number of threads independently
of worker_connections.
|
|
coolio_thread_pool, neverblock both use it, and
xepoll_thread_pool will support it next, too.
|
|
Just the test name is irrelevant
|
|
This is probably friendlier on server resources in the worst
case than XEpollThreadSpawn but may perform worse in the client
client-visible way, too.
|
|
Fixed in kgio 2.4.0 now
This reverts commit a1168e7d2bfe182896f139d051ef099616fd1646.
|
|
No need for a string comparison
|
|
kgio 2.4.0 has some 1.9.3dev fixes which affect us
|
|
We only poll for one event (EPOLLIN/EPOLLOUT) at a time,
so there's no need to actually check since they're too
rare.
|
|
worker_yield is safer than setting a threshold with multiple
acceptors when thread limits are hit. Also, avoid sleep +
Thread#run since it's potentially racy if threads are extremely
unfairly scheduled.
Same things applied to xepoll_thread_spawn.
|
|
Infinite sleep is too dangerous due to possible race conditions,
so use worker_yield which is safer and cheaper in the general
case. We can also avoid sleeping on new threads by only
spawning when the client module is included.
|
|
Otherwise pipeline_ready can false positive on us
|
|
shorter line and 3 lines of code killed!
|
|
Not that it's actually used, right now.
|
|
|
|
Newer versions should be better
|
|
More sharing, faster startups, and most importantly,
better error reporting if some things are missing.
|
|
It *can* have as many threads as it does idle connections.
|
|
We won't forget to reset defaults on SIGHUP anymore.
|
|
Too confusing otherwise...
|