Date: Sun, 4 Nov 2012 12:29:58 -0800 (PST)
From: Jonathan Rochkind <rochk...@jhu.edu>
To: thin-ruby@googlegroups.com
Message-Id: <23ef506a-00a3-4c55-9832-223a8c6e0268@googlegroups.com>
In-Reply-To: <CACkZu0okkYNb92oe7s9tzhFRKYpbsSh9wbF+rOrotaYDBxjg2Q@mail.gmail.com>
References: <CACkZu0rWNgZ3X5xwc6=K-6Vu_KP9YXiYPU8dVUhf8DgRjkVNuQ@mail.gmail.com>
 <47082ce6-6645-4ce8-81c9-aef4e8205cd4@googlegroups.com>
 <CACkZu0okkYNb92oe7s9tzhFRKYpbsSh9wbF+rOrotaYDBxjg2Q@mail.gmail.com>
Subject: Re: Thin 2.0 pre-release
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1391_18095675.1352060998180"

------=_Part_1391_18095675.1352060998180
Content-Type: multipart/alternative; 
	boundary="----=_Part_1392_30201579.1352060998180"

------=_Part_1392_30201579.1352060998180
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

> - Optional threaded mode using a pool of threads. (If your app code is 
slow)

I'm actually particularly excited about that feature, I hope it makes it in 
and becomes a mature and robust feature. 

Single-process multi-threaded request handling can actually result in a lot 
of capacity not only if your app code is slow -- but if your app is I/O 
bound, as many apps are -- if your app is I/O bound, then even on MRI with 
the GIL.   And could be a cheaper option to handle more traffic on 
platforms that charge per-process (heroku, more or less), compared to 
multi-process scale-out. 

Rails 4.0 is slated to have `config.threadsafe!` on by default at least in 
production 
(http://tenderlovemaking.com/2012/06/18/removing-config-threadsafe.html). 
 But it wont' matter if hardly anyone is using an app server that can do MT 
concurrent request dispatching.  thin being able to do so could really open 
that up to 'the masses'.  (right now upcoming Passenger Enterprise will do 
it, but not free passenger. puma will do it. Not sure about others).   And 
the more you can open up concurrent request handling in Rails and the more 
people using it, the more likely the remaining bugs and mis-designs in 
rails around multi-threaded concurrency will be noted and fixed. 
 

------=_Part_1392_30201579.1352060998180
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

&gt;&nbsp;- Optional threaded mode using a pool of threads. (If your app co=
de is slow)<div><div><br></div><div>I'm actually particularly excited about=
 that feature, I hope it makes it in and becomes a mature and robust featur=
e.&nbsp;</div><div><br></div><div>Single-process multi-threaded request han=
dling can actually result in a lot of capacity not only if your app code is=
 slow -- but if your app is I/O bound, as many apps are -- if your app is I=
/O bound, then even on MRI with the GIL. &nbsp; And could be a cheaper opti=
on to handle more traffic on platforms that charge per-process (heroku, mor=
e or less), compared to multi-process scale-out.&nbsp;</div><div><br></div>=
<div>Rails 4.0 is slated to have `config.threadsafe!` on by default at leas=
t in production (http://tenderlovemaking.com/2012/06/18/removing-config-thr=
eadsafe.html). &nbsp;But it wont' matter if hardly anyone is using an app s=
erver that can do MT concurrent request dispatching. &nbsp;thin being able =
to do so could really open that up to 'the masses'. &nbsp;(right now upcomi=
ng Passenger Enterprise will do it, but not free passenger. puma will do it=
. Not sure about others). &nbsp; And the more you can open up concurrent re=
quest handling in Rails and the more people using it, the more likely the r=
emaining bugs and mis-designs in rails around multi-threaded concurrency wi=
ll be noted and fixed.&nbsp;</div><div>&nbsp;<br></div></div>
------=_Part_1392_30201579.1352060998180--

------=_Part_1391_18095675.1352060998180--