On 9/13/07, Prateek <[EMAIL PROTECTED]> wrote: > On Sep 13, 1:36 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > Prateek wrote: > > > Hi, > > > > > Recently there was some talk on removing the GIL and even the BDFL has > > > written a blog post on it. > > > I was trying to come up with a scalable and backwards compatible > > > approach for how to do it. > > > > > I've put my thoughts up in a blog post - and I'd really like to hear > > > what the community thinks of it. > > > Mainly it revolves around dedicating one core for executing > > > synchronized code and doing context switches instead of acquiring/ > > > releasing locks. > > > > Where is the gain? Having just one core doesn't give you true parallelism - > > which is the main reason behind the cries for a GIL-less Python. > > > > Diez > > Diez, > > I was talking of dedicating one core for synchronized code. In the > case of a threaded app on two cores, one core would be dedicated to > synchronized code and the other would run non-sync code (effectively > behaving like a single threaded machine). However, on machines with n > cores where n > 2 cores, we would have n-1 cores available to run code > in parallel. >
What you're describing would have the same characteristics as the current code - code that is able to execute without the GIL held already will run in parallel on a multi-core machine. -- http://mail.python.org/mailman/listinfo/python-list
