using python interpreters per thread in C++ program

[Benjamin Kaplan]

On Mon, Sep 7, 2009 at 6:31 PM, Mark Hammond<skippy.hammond at gmail.com> wrote:
> On 7/09/2009 10:50 PM, MRAB wrote:
>>
>> sturlamolden wrote:
>>>
>>> On 7 Sep, 13:53, ganesh <ganeshbo... at gmail.com> wrote:
>>>
>>>> I need to use these to get the proper concurrency in my multi-threaded
>>>> application without any synchronization mechanisms.
>>>
>>> Why will multiple interpreters give you better concurrency? You can
>>> have more than one thread in the same interpreter.
>>>
>>> Here is the API explained:
>>>
>>> http://docs.python.org/c-api/init.html
>>> http://www.linuxjournal.com/article/3641
>>
>> CPython's GIL means that multithreading on multiple processors/cores has
>> limitations. Each interpreter has its own GIL, so processor-intensive
>> applications work better using the multiprocessing module than with the
>> threading module.
>
> I believe you will find the above is incorrect - even with multiple
> interpreter states you still have a single GIL.
>
not according to the docs.

http://docs.python.org/library/multiprocessing.html :

multiprocessing is a package that supports spawning processes using an
API similar to the threading module. The multiprocessing package
offers both local and remote concurrency, effectively side-stepping
the Global Interpreter Lock by using subprocesses instead of threads.
Due to this, the multiprocessing module allows the programmer to fully
leverage multiple processors on a given machine. It runs on both Unix
and Windows.
> Mark
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>