On Wed, Nov 18, 2009 at 12:20 PM, pharrington <xenogene...@gmail.com> wrote:
> On Nov 18, 1:43 pm, Conrad Taylor <conra...@gmail.com> wrote: > > Each thread must acquire the lock before it can execute. Thus, it > operates > > similar to a queue data structure (i.e. first in first out (FIFO)) and > this > > is how > > it work today in regards to Ruby 1.8.6, 1.8.7, and 1.9.1. I know the C > > implementation > > of the Ruby VM very well. > > > > -Conrad > > The C code will acquire the GIL yes, and then release it when its done > its bit of business. This will happen any number of times within a > given function. So yes while the first thread created is the first to > run its bit of code, in no way does that mean its the first thread to > finish, nor does it stop the interpreter from switching control to > another than when the lock is given up in the middle of execution. > Saying Ruby threads don't run in parallel is even less true than > saying coroutines aren't a form of parallelism. > > > Actually, the C doesn't require a GIL because it's being executed outside the VM within its own process. Thus, one can simulate very good parallel execution using something like BackgroundRB because it's implemented as a Ruby native-extension. -Conrad > > On Nov 18, 3:00 pm, jhaagmans <jaap.haagm...@gmail.com> wrote: > > The reason why we didn't choose jRuby was because it uses too much > > memory to be able to run this on a VPS. Is there any documentation > > available on using jRuby on a low-memory (<256MB) system? I've looked > > for it, but couldn't find it. Maybe there's an alternative workaround > > for the GIL? Our application uses up quite alot of memory, so when > > presented with the jRuby vs. Ruby (EE) question, I thought it was a > > choice between thread safety and memory usage, so I chose the latter. > > I didn't know there was more to think about. > > > > > Regardless, I can't seem to reproduce the OPs behviour: > > > > Which Ruby implementation are you using? I'm very sure every thread in > > my piece of code is waiting for the other thread to finish, because I > > log the time at which the data is saved. Most of the time there's 10 - > > 40 seconds between them, even though the backgroundrb process should > > save at least one object every second. > > x...@clover:~/projects$ ruby -v > ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] > > > Threading's not the issue. Try looking into Lionel's suggestion; > perhaps things will work as expected if you switch to delayed_job > instead of BackgroundRB, or posssssibly even just a different HTTP > client like curb. Or perhaps the problem's not related to the HTTP > fetching at all and we don't have the whole story. > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-t...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com<rubyonrails-talk%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=.
