If the threads under discussion are all Python threads, then by default yes, the extension module C functions will appear to be atomic from the perspective of the Python code. When the Python code calls into the extension module, the GIL (global interpreter lock) is still being held. Unless the extension module code explicitly releases the GIL, no other Python threads can execute (even though those threads are in fact implemented as native platform threads).
Indeed, there is this (so annoying) GIL ... is there any project about extracting the (few ?) critical points of the python interpreter to put locks around them instead of choosing the opposite strategy (ie. locking anythime but when we know the section is not critical) ? Because it would made embedding a python interpreter in another language much more easy !
With the current CPython, it's very hard to mix Python and C in a multithreading application (with C-threads, not Python-threads). In fact I never really succeeded in that task because of that GIL ! I have a multi-thread application but every bit of Python code must be run into a Python thread. To be more precise, I wanted to be able to call Python code in response to some GUI events, and I didn't want to instanciate a new interpreter for I wanted to be able to access the environment of my main Python interpreter.
By the way, if someone succeeded in a similar task, I'll be happy to hear about it :)
Pierre
PS: if the main code is in C (in fact C++ ...) and not Python it's for historical reasons of course ;)
--
http://mail.python.org/mailman/listinfo/python-list
