[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: Some interesting criticisms of rails
From:       Joe Van Dyk <joevandyk () gmail ! com>
Date:       2005-09-17 6:29:26
Message-ID: c715e6405091623296c0a5e84 () mail ! gmail ! com
[Download RAW message or body]

On 9/16/05, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> 
> I remember reading about the Dining Philosophers problem when I was young and how \
> it was solved with this incredibly complex logic proof that laid out most of the \
> rules for what we know as "thread locking".  For those of you who don't know, the \
> Dining Philosophers is where there's four idiots arguing about communism eating a \
> massive bowl of pasta and they're too stupid to ask for more than two serving \
> forks.  So, these "philosophers" spend a lot of time fighting over the forks and \
> there needs to be a way to coordinate this fork "sharing".  The solution?  Ah, \
> we'll add even more complexity to the problem and create neat things like \
> semaphors.

I remember that from a recent Operating Systems class.  So it's still
in use today.
 
> Of course another way to solve the Dining Philosophers problem is: USE A FUCKING \
> WAITER.  You see, if these idiots don't serve themselves--but instead get their \
> pasta from a "server"--then you don't have anybody arguing over shared forks.  \
> Hmmmm.  "Server".  I wonder why we call systems that act as a single access point \
> to a service "servers"?  Gee.  That just stumps my tired little brain.

I should've brought that up to the professor.  :(


 
> What's that got to do with the world of distributed transaction management?  Well, \
> you only need to have complicated distributed locking primitives when you try to \
> distribute your shared resources to the point that people have to fight over them.  \
> If you just have a "server" that controls access and "share nothing" then the \
> problem is solved in a much simpler way. 
> And BTW, if you've ever seen a gang of philisophical communists duel with forks for \
> the last serving of fusili then you'll realize that letting communists share is not \
> nearly as fast as having a waiter serve. 
> Zed A. Shaw
> http://www.zedshaw.com/
> 
> 
> On Sat, 17 Sep 2005 04:36:35 +0900
> David Balick <davidbalick@gtakethisoutmail.com> wrote:
> 
> > may be found in the podcast
> > http://www.drunkandretired.com/2005/06/drunkandretired-podcast-episode-
> > 09.html.
> > 
> > I am considering using rails (as opposed to asp.net) so am wondering what
> > y'all think of what these guys say.
> > 
> > In a nutshell, they say that Rails starts to get less appropriate for apps
> > with transactions that encompass entities other than just the database. If
> > the server side objects also modify the data, and particularly of the
> > modified objects then affect other objects, then it can become very non-
> > trivial to handle all of that in Rails.
> > 
> > Any feedback on this from experienced Rails folk would be most appreciated.
> > 
> > Cheers,
> > David Balick
> > 
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]