Date | Commit message (Collapse) |
|
We were needlessly allocating objects even when using yield.
|
|
acceptor thread pools could use some work, still
|
|
There's a lot of code duplication here :<
|
|
Array#each will do..
|
|
Avoid constantly nuking the method cache and raising
repeated exceptions while our master process is shutting
us down.
|
|
Ugh, I need to think of a way to clean this up...
|
|
We want to use the singleton methods in Kgio to reduce
conditionals.
|
|
It's too long especially since XEpollThreadPool is planned :>
|
|
It supports IPv6 and pulls in a better Kgio. Since Unicorn
defaults to ":tcp_nopush => true", we need to flip it back
to false to be compatible with the types of apps Rainbows!
is targetted as.
|
|
Put all of our constants in one place for easy reference
|
|
Yes it's fugly
|
|
We can't work around it effectively in the C extension
itself. This requires the latest sleepy_penguin gem.
|
|
This can be a starting point for developing Cool.io or
EventMachine-based reverse proxy applications on Rainbows!
Eventually Rainbows! could replace nginx for Unicorn users!
Just don't consider this code production ready, yet, at all,
it doesn't handle any sort of failover and has no automated
tests, yet.
|
|
This allows us to more aggressively handle pipelining
as well as trigger future Kgio autopush behavior.
|
|
We should only attempt to modify the descriptor when we
block, and not for subsequent events.
|
|
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.
|
|
We're living on the EDGE and mixing epoll with threads :D
|
|
We'll be using this more in the future
|
|
super doesn't seem to capture arguments inside a block
under 1.8.7 :<
|
|
No reason to keep it around
|
|
We know @wr_queue is empty since we just initialized it
and the first thing an HTTP client does is read.
|
|
No need to setting an ivar for most requests
|
|
We'll override it, maybe...
|
|
We don't do Level-Triggered I/O around here
|
|
We'll lower our precision for keepalive timeouts a little
and and reduce our Time object allocation rate.
|
|
We don't need to allocate new string objects for short-lived
strings. We'll pay the price of a constant lookup instead.
|
|
We can eliminate the State module to simplify our code
since 1.3.x keeps better track of things.
|
|
It's almost just like Coolio
|
|
It was based off the nginx window of 64 events. Not that
any servers are really that busy...
|
|
This allows us to gracefully shutdown more quickly.
|
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
Nothing we can do about that from clients. Perhaps kgio
should just return nil for those...
|
|
ev_core is always loaded after forking, so eliminate the
need for extra setup steps for each concurrency model that
uses it
|
|
It turns out to be less-used than previous anticipated,
so there's no point in having yet another module.
|
|
It's the only place we ever use it
|
|
We handle that locally in rainbows/response now
|
|
Constant strings mean the runtime won't have to allocate new
objects all the time since GC is currently the biggest
performance problem of Ruby 1.9.x in my experience.
|
|
chunked Transfer-Encoding is only valid for HTTP/1.1
|
|
We guarantee the Rack env will exist for the duration of
the request/response cycle, so we can just tweak
"rainbows.autochunk".
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
Single-threaded concurrency models can reuse a single
buffer to avoid thrashing memory and causing unnecessary
GC activity.
|
|
There is one incompatible change: We no longer assume application
authors are crazy and use strangely-cased headers for "Content-Length",
"Transfer-Encoding", and "Range". This allows us to avoid the
case-insensitivity of Rack::Utils::HeaderHash for a speed boost on the
few apps that already serve thousands of requests/second per-worker.
:Coolio got "async.callback" support like :EventMachine, but it
currently lacks EM::Deferrables which would allow us to call
"succeed"/"fail" callbacks. This means only one-shot response writes
are supported.
There are numerous internal code cleanups and several bugfixes for
handling partial static file responses.
|
|
We cannot trigger on_read events and invoke the HTTP parser and
modify @env while we're waiting for an application to run
async.callback. We also need to clear (and *maybe* re-set)
@deferred if we're writing from async.callback
|
|
Both use @deferred to refer to the state where there's a
deferred response body in the queue.
|
|
Nobody uses it anymore
|
|
The lack of an equivlent to EM::Deferrable prevents us from
doing streaming/trickling responses, but a one-shot body
should work fine for Coolio and generating dynamic responses.
|
|
It's more natural and easier to maintain this way
since Coolio::Client is always lazy loaded.
|
|
* lazy load uncommon classes: StreamFile, Response{Chunk,}Pipe
* remove needless rainbows/coolio/sendfile module since we're
lazily loaded now along with the rest of rainbows/coolio/client
and only in the worker.
|
|
We don't want that loaded in the parent process since
we want config reloadability.
|
|
No point in having too many modules to search around
(for both hackers and the runtime).
|