On Nov 18, 1:43 pm, Conrad Taylor <[email protected]> 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. On Nov 18, 3:00 pm, jhaagmans <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
