On Thu, Aug 24, 2006 at 01:46:11PM -0700, Jeremy Kemper wrote:> On 8/24/06, snacktime <snacktime@gmail.com> wrote: > > Maybe I''ve missed it, but I havent'' seen any of the core team talk > > about whether they plan on fixing this in the near future or not. It > > seems to me that making rails thread safe would do more to enhance > > rails then any other single thing that could be done. > > Why?I''m not quite as emphatic as snacktime when it comes to the importance of a thread-safe Rails, but it *would* do something to reduce the size of Mongrel packs (presumably), and (of more immediate importance to me) it would lift a big performance bottleneck in a Rails app I''m writing for an internal customer, where I need to query a bunch of web services and collate the info; having to do that single-threaded (because Rails requests are wrapped in a giant mutex) is killing response time for me. (Yes I''ve hacked around the problem, sorta, with forking, but it''s so.... icky). I know it''s a pretty esoteric requirement, and not particularly broad-spectrum, but *I''d* certainly be interested in any effort to remove or reduce the thread-safety issues in Rails. - Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Jeremy Kemper
2006-Aug-25 00:05 UTC
Re: [Rails] Making rails thread safe, priority or not?
On 8/24/06, Matt Palmer <mpalmer@hezmatt.org> wrote:> > On Thu, Aug 24, 2006 at 01:46:11PM -0700, Jeremy Kemper wrote: > > Why? > > I''m not quite as emphatic as snacktime when it comes to the importance of > a thread-safe Rails, but it *would* do something to reduce the size of > Mongrel packs (presumably), and (of more immediate importance to me) it > would lift a big performance bottleneck in a Rails app I''m writing for > an internal customer, where I need to query a bunch of web services and > collate the info; having to do that single-threaded (because Rails > requests > are wrapped in a giant mutex) is killing response time for me. (Yes I''ve > hacked around the problem, sorta, with forking, but it''s so.... icky).Birthing new mongrels in your pack is not an option? I think yours is the best case for better single-process concurrency - apps that aren''t hitting a db. I know it''s a pretty esoteric requirement, and not particularly> broad-spectrum, but *I''d* certainly be interested in any effort to remove > or > reduce the thread-safety issues in Rails.Awesome! We have a handful of volunteers; let''s rub some code together. How about starting with a test suite for each component demonstrating where it isn''t thread-safe? jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
On Thu, Aug 24, 2006 at 05:05:28PM -0700, Jeremy Kemper wrote:> On 8/24/06, Matt Palmer <mpalmer@hezmatt.org> wrote: > > > > On Thu, Aug 24, 2006 at 01:46:11PM -0700, Jeremy Kemper wrote: > > > Why? > > > > I''m not quite as emphatic as snacktime when it comes to the importance of > > a thread-safe Rails, but it *would* do something to reduce the size of > > Mongrel packs (presumably), and (of more immediate importance to me) it > > would lift a big performance bottleneck in a Rails app I''m writing for > > an internal customer, where I need to query a bunch of web services and > > collate the info; having to do that single-threaded (because Rails > > requests > > are wrapped in a giant mutex) is killing response time for me. (Yes I''ve > > hacked around the problem, sorta, with forking, but it''s so.... icky). > > > Birthing new mongrels in your pack is not an option? I think yours is theNot really, since the results of all of the different web services queries need to be aggregated into a single page and displayed to the user, all in real-time. I''m currently using forks to do the gathering in parallel, but it''s not real good.> I know it''s a pretty esoteric requirement, and not particularly > > broad-spectrum, but *I''d* certainly be interested in any effort to remove > > or > > reduce the thread-safety issues in Rails. > > Awesome! We have a handful of volunteers; let''s rub some code together. How > about starting with a test suite for each component demonstrating where it > isn''t thread-safe?I think the suggestion to just pull the mutex and start hammering in some requests is a good start to at least get a feel for how much pain and suffering there''s likely to be. Unfortunately, to ensure that we''ve *really* gotten all the bugs, we''ll need to audit all the code and verify that it''s problem-free (or fix the problems). We could use the tightening noose method -- as we audit various parts of the code, the global mutex just wraps less and less of the code; eventually it should just wrap code that we *cannot* make thread-safe (external libraries, for instance) and user methods (we can''t guarantee the thread-safety of that code, so it''ll need to be kept on a leash). Ultimately, though, the problem may require larger solutions -- changes in the coding practices of all contributors, or at least a constant vigilance on all committed code to ensure it''s not introducing thread safety problems. I suspect that ultimately this might be the biggest hurdle to getting Rails thread-safe across the board. As Rasmus Lerdorf is fond of saying, "people aren''t smart enough to write thread-safe code" -- it''s excruciatingly difficult to get right. Anyone up for Erlang on Rails? <grin> - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace "special tool no. 2-112-A" -- Matt Roberds in asr. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---