Date | Commit message (Collapse) |
|
Not that many people will actually call Rainbows.sleep
outside of tests...
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
Every concurrency model does this the same way.
This removes the Rainbows::Const::LOCALHOST constant and
may break some existing apps that rely on it.
|
|
It's generally dangerous to do so regardless of language and
Ruby 1.9.2dev is stricter about this sort of behaviour.
|
|
For the very rare apps out there using Rainbows::Fiber::IO, the
FiberSpawn and FiberPool (but not RevFiberSpawn) models could
leak memory if the app-created Rainbows::Fiber::IO objects
were dereferenced without being removed from the RD/WR hashes.
|
|
When available (Ruby 1.9), we can use Hash#compare_by_identity
to improve performance.
|
|
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).
|
|
This is like the traditional FiberSpawn, but more scalable (but
not necessarily faster) as it can use epoll or kqueue.
|
|
|
|
This makes them easier to override in subclasses.
|
|
This exposes a client IO object directly to the underlying
application.
|
|
While we're at it, ensure our encoding is sane
|
|
While Revactor uses Fiber::Queue in AppPool, we don't want/need
to expose the rest of our Fiber stuff to it since it can lead to
lost Fibers if misused. This includes the Rainbows::Fiber.sleep
method which only works inside Fiber{Spawn,Pool} models and
the Rainbows::Fiber::IO wrapper class.
|
|
Both FiberSpawn and FiberPool share similar main loops, the
only difference being the handling of connection acceptance.
So move the scheduler into it's own function for consistency.
We'll also correctly implement keepalive timeout so clients
get disconnected at the right time.
|
|
This enables the safe use of Rainbows::AppPool with all
concurrency models, not just threaded ones. AppPool is now
effective with *all* Fiber-based concurrency models including
Revactor (and of course the new Fiber{Pool,Spawn} ones).
|
|
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.
|