On 9/5/06, Luis Lavena <[EMAIL PROTECTED]> wrote: > Anyway, the use of thread.critical isn't a viable locking method, as > said by ruby-core by matz a few years back (1.6 version I think).
Thread.critical alone makes it easy to get oneself into trouble, but both Sync and Mutex are built on top of it. > The really funny part is that, based on your interpretation of the > problem, why the GC of both platforms behave differently? I think the differences observed between Linux and WinXP relate to how each platform's memory management interacts with Ruby. BTW, although switching Mutex to using a linked list for the thread queue worked great, it appears that one can get Ruby to do reasonable things with the array by switching the push in lock and the shift in unlock to be an unshift and a pop, respectively. This is because pop will realloc the array. I haven't yet tested that as extensively as I did the mutex with linked list, but so far it appears solid. > I know that ruby GC isn't the fastest, nor the optimal (nor even as > good as other, simplistic GC around the net). The whole mark and sweep > method is too "intensive". > > But, why the differences between platforms? even as you said what do > Mutex and what do Sync... ruby-mswin32 (stable from official build, > vc6) do garbage collect of Mutex when linux doesn't? That really just looks like a difference in platform memory management interaction with Ruby. The fixes (linked list or changing array operations) both appear to work identially on Linux and WinXP, though, without incurring the speed penalty that Sync has. I'm doing more testing this week, though, on both Linux and WinXP. I'll send out updates here and on ruby-talk if I find anything else that is useful or interesting. Kirk _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
