Re: [sunshowers] Does using ThreadPool concurrency tie up a thread per socket
- From:
- Eric Wong
- Date:
- 2010-10-21 @ 19:29
Nathan Sobo <nathansobo@gmail.com> wrote:
> Does using Sunshowers with ThreadPool tie up a thread for every web
> socket connection? It seems like I'd end up with a lot of threads as
> the number of clients went up. I just want to send messages to clients
> via sockets, not read from the sockets. Is it possible to just store
> off the web socket io object and terminate the request, then write to
> it from another thread? Or am I completely off base entirely and
> should be using another approach? Thanks!
Yes, ThreadPool and ThreadSpawn with Rainbows! is a 1:1 mapping of
Threads to sockets.
One thing you could do is IO#dup the socket IO object (which internally
does a dup() syscall) and send the dup'ed descriptor to Sunshowers
dup_env = env.dup
dup_env["hack.io"] = env["hack.io"].dup
req = Sunshowers::Request.new(dup_env)
Then you can use the "req" object outside of the normal dispatch
in another thread.
I wouldn't worry too much for now, Threads are pretty good for
concurrency with Ruby 1.8 with green threads, and probably fine for 1.9,
too. With 1.9 and native threads, you'll pay 512K of stack memory
per-client.
If you want better scalability under 1.9, use FiberPool or FiberSpawn
and you'll only have a 4K stack per-client (socket buffers are typically
larger than that), but if you have external dependencies (Net::HTTP,
database drivers), you'll have to make sure those work with Fibers
(and possibly contribute to NeverBlock or similar efforts).
--
Eric Wong