On May 20, 8:59 am, Luis Zarrabeitia <ky...@uh.cu> wrote: > On Monday 18 May 2009 10:31:06 pm Carl Banks wrote: > > > Even if you decided to accept the penalty and add locking to > > refcounts, you still have to be prepared for context switching at any > > time when writing C code, which means in practice you have to lock any > > object that's being accessed--that's in addition to the refcount lock. > > While I agree that the GIL greatly simplifies things for the interpreter, I > don't understand this statement. In practice, you should lock all critical > sections if you expect your code to be used in a multithreading environment. > That can't be different from what Java, C# or any other languages do, > including C++. Why is that so expensive in python extensions, that it is used > as an argument against removing the GIL?
I wasn't really arguing that locking individual objects was a significant penalty in computer time, only in programmer time. The locks on reference counts are what's expensive. Also, I'm not using it as an argument against removing the GIL. I want to remove the GIL. I'm only pointing out that removing the GIL is not easy, and once it's removed there is a cost. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
