On May 20, 4:07 pm, Luis Zarrabeitia <ky...@uh.cu> wrote: > On Wednesday 20 May 2009 06:16:39 pm Aahz wrote: > > > >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? > > > Python is intended to be simple/easy to integrate with random C > > libraries. Therefore you have to write explicit code from the C side in > > order to drop the GIL. > > Erm, that doesn't really answers the question. If there were no GIL, the C > code called from python would be just as unsafe as the C code called from C. > And if "not thread-safe, you take care of the locking" notices are enough for > the original libraries (and a lot of other languages, and even python > constructs), the C extension could always grab the locks.
The designers of Python made a design decision(**) that extension writers would not have to take care of locking. They could have made a different decision, they just didn't. > There must be another reason (i.e, the refcounts) to argue _for_ the GIL, Why? > because this one just seems to be just an attempt to fix unsafe code when > called from python. I think you are being unfair in calling it unsafe. Suppose if I were to call PyList_Append from a C extension. It's not necessary for me to guard the list I'm calling it on with a lock, because only the GIL thread is allowed to call most Python API or otherwise access objects. But you seem to be suggesting that since I didn't guard the list with a lock it is "unsafe", even though the GIL is sufficient? No, I totally disagree. The code is not "unsafe" and the GIL doesn't "fix" it. The code is jsut > And that was my point. Refcounts + interpreter simplicity > seem to imply the need for a GIL, but to make unsafe code safe without fixing > said code (or even thinking about it) is a weird goal... Why? Do you seriously not see the benefit of simplifying the work of extention writers and core maintainers? You don't have to agree that it's a good trade-off but it's a perfectly reasonable goal. I highly suspect Aahz here would argue for a GIL even without the refcount issue, and even though I wouldn't agree, there's nothing weird or unreasonable about the argument, it's just a different viewpoint. > specially if it > became the only reason for a GIL. After all, one could argue for that goal in > almost all languages. "B-B-B-But other languages do it that way!" is not a big factor in language decisions in Python. Carl Banks (**) - To be fair, Python didn't originally support threads, so there was a lot of code that would have become unsafe had threading been added without the GIL, and that probably influenced the decision to use a GIL, but I'm sure that wasn't only reason. Would Python have a GIL if threading had been there from the start? Who knows. -- http://mail.python.org/mailman/listinfo/python-list
