[Python-Dev] Making python C-API thread safe (try 2) (original) (raw)
Martin v. Löwis martin at v.loewis.de
Thu Sep 11 21:54:11 EDT 2003
- Previous message: [Python-Dev] Making python C-API thread safe (try 2)
- Next message: [Python-Dev] Making python C-API thread safe (try 2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Harri Pesonen <fuerte at sci.fi> writes:
The change is trivial in Python C API. I already said that it would break everything outside the Python distribution, but the change in other applications is also trivial.
If it is trivial, would you mind posting a patch somewhere?
> You misunderstand. Those "critical sections" are for the most part > in Python's C code, not in the Python script.
Yes, I'm aware of the None problem at least (only one instance of it). Please enlighten me about the other critical sections? Object allocation/freeing?
Yes, that, plus:
- allocation of/access to small numbers
- access to global variables in extension modules (e.g. cursesmodule.c:PyCursesError)
- type objects etc.
Of course, changing Python to not have a single None would help a lot. Or, perhaps it could have a single None, but in case of None, the reference count would have no meaning, it would never be deallocated, because it would be checked in code. Maybe it does it already, I don't know.
So how can you know a patch would be trivial?
I'm also wondering why this problem has not been addressed before? If I had the power to change Python, this would be the first thing I did.
Please go ahead and post a patch. You might find that the patch is difficult to write, and, once written, will have many errors. Once those are fixed, you might find that Python becomes painfully slow, and lose a lot of portability.
Regards, Martin
- Previous message: [Python-Dev] Making python C-API thread safe (try 2)
- Next message: [Python-Dev] Making python C-API thread safe (try 2)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]