Adding a Par construct to Python?

[Luis Zarrabeitia]

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.

There must be another reason (i.e, the refcounts) to argue _for_ the GIL, 
because this one just seems to be just an attempt to fix unsafe code when 
called from python. 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... specially if it 
became the only reason for a GIL. After all, one could argue for that goal in 
almost all languages.

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie