From: barjunk Date: 2008-07-03T01:27:12+09:00 Subject: Re: Threads and Ruby On Jul 1, 8:49 am, "ara.t.howard" wrote: > On Jul 1, 2008, at 10:33 AM, Joel VanderWerf wrote: > > > Yes, sqlite does synchronize, but a potential problem is > > granularity: a writer gets an exclusive lock on the entire db. > > but only very briefly, in practice the throughput is close to what you > can achieve with mutexes combined with the mri thread scheduler > > http://www.sqlite.org/lockingv3.html > > one of the reasons this is true is that for a heavily threaded ruby > program (green threads) you end up with the entire process sometimes > blocked on io and the threads end up getting into a pattern where all > of them need to write at once - a kind of rhythm - with processes the > ability for the OS to schedule access to resources ends up staggering > the phase of execution so access is generally faster than it 'ought' > to be taking only TPS into account. > > this a *wild* generalization based only on the kinds of parallel > processing i've done, but i've seen the pattern where a heavily > threaded program ends up being effectively serial enough times to > mention it... > > a @http://codeforpeople.com/ > -- > we can deny everything, except that we have the possibility of being > better. simply reflect on that. > h.h. the 14th dalai lama OK, I'm going to try to recap what I learned so far from reading links and making some assumptions (*bad*): 1 - Green threads are threads that run in user space. 2 - Forking allows for running multiple ruby interpreters, each with their own memory space. 3 - Ruby provides a thread mechanizm, but these threads are serialized. 4 - Native threads are used in Jruby, and in Ruby 1.9 YARV 5 - If you use ruby threads, each thread shares the memory space of all the others. Hopefully I hit on all the major points that were made. It looks like forking is what I'm looking for in my use case: - I want sandboxing for each 'thread' - I don't want one 'thread' to block another Thanks for the discussion guys. Seems like there is more to be learned though. Mike B.