On Sep 8, 9:28 am, Mark Hammond wrote:
> I was referring to the
> 'multiple interpreters in one process' feature of Python which is
> largely deprecated, ...
Can you please point to where in the documentation for Python it says
that support for multiple interpreters in one process is 'largely
dep
On 8 Sep, 09:14, ganesh wrote:
> No, i cannot change from threads to processes for handling
> connections. This will change the complete design of our application
> which is not feasilbe for python evaluation of the strings.
So the problem is actually bad design?
--
http://mail.python.org/mailm
On 8 Sep, 08:46, I V wrote:
> Do you have to use threads? If you use a process per connection, rather
> than a thread, each process will have its own GIL.
If ganesh is using Linux or Unix (which pthreads indicate), fork() is
just as efficient as threads.
On Windows one would need to keep a farm
On Sep 8, 2:46 pm, I V wrote:
> Do you have to use threads? If you use a process per connection, rather
> than a thread, each process will have its own GIL.
No, i cannot change from threads to processes for handling
connections. This will change the complete design of our application
which is not
On 8 Sep, 04:22, ganesh wrote:
> My application is a TCP server having multiple client connectons. C++
> PTHREADS are for each connected socket and the message received on the
> socket is evaluated by python functions.
> If I use only one process level python interpreter, then every thread
> has
On Mon, 07 Sep 2009 19:22:17 -0700, ganesh wrote:
> My application is a TCP server having multiple client connectons. C++
> PTHREADS are for each connected socket and the message received on the
> socket is evaluated by python functions. If I use only one process level
Do you have to use threads?
My application is a TCP server having multiple client connectons. C++
PTHREADS are for each connected socket and the message received on the
socket is evaluated by python functions.
If I use only one process level python interpreter, then every thread
has to lock the GIL & so blocking the other thr
On 2009-09-07, Mark Hammond wrote:
> Sorry, my mistake, I misread the original - using multiple
> Python processes does indeed have a GIL per process. I was
> referring to the 'multiple interpreters in one process'
> feature of Python which is largely deprecated, but if used,
> all 'interpreters
On 8/09/2009 9:16 AM, Grant Edwards wrote:
On 2009-09-07, Mark Hammond wrote:
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 t
On 2009-09-07, Mark Hammond wrote:
>> 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
On Mon, Sep 7, 2009 at 6:31 PM, Mark Hammond wrote:
> On 7/09/2009 10:50 PM, MRAB wrote:
>>
>> sturlamolden wrote:
>>>
>>> On 7 Sep, 13:53, ganesh wrote:
>>>
I need to use these to get the proper concurrency in my multi-threaded
application without any synchronization mechanisms.
>>>
>>>
On 7/09/2009 10:50 PM, MRAB wrote:
sturlamolden wrote:
On 7 Sep, 13:53, ganesh 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
On 7 Sep, 14:50, MRAB wrote:
> 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.
We incur a 200x speed-pena
sturlamolden wrote:
On 7 Sep, 13:53, ganesh 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.
On 7 Sep, 13:17, Ulrich Eckhardt wrote:
> Quoting from above: "The GIL is global to the process". So no, it is NOT
> private to each thread which means "python" isn't either.
>
> At least that is my understanding of the issue.
Strictly speaking, the GIL is global to the Python DLL, not the
proce
On 7 Sep, 13:53, ganesh 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 ex
Actually, I modified my program to have a single shared Py-interpreter
across all threads to test the usage of GIL. So, I did Py_Initialize
in main() function and only called that python function in different
threads.
But this is not the way I want to use interpreters in my code.
I am looking for
ganesh wrote:
>> Did you remeber to acquire the GIL? The GIL is global to the process
>
> No, I did not use GIL.
>
> -- Why do we need to use GIL even though python is private to each
> thread?
Quoting from above: "The GIL is global to the process". So no, it is NOT
private to each thread which
On Sep 7, 6:47 pm, ganesh wrote:
> On Sep 7, 3:41 pm, Graham Dumpleton
> wrote:
>
> > On Sep 7, 3:42 pm, sturlamolden wrote:
> > interpreters. The simplified GIL state API you mentioned only works
> > for threads operating in the main (first) interpreter created within
> > the process.
>
> I mod
On Sep 7, 3:41 pm, Graham Dumpleton
wrote:
> On Sep 7, 3:42 pm, sturlamolden wrote:
> interpreters. The simplified GIL state API you mentioned only works
> for threads operating in the main (first) interpreter created within
> the process.
I modified my program to have Py_Initialize and compilat
On Sep 7, 3:42 pm, sturlamolden wrote:
> On 7 Sep, 07:17, grbgooglefan wrote:
>
> > What is best way to embed python in multi-threaded C++ application?
>
> Did you remeber to acquire the GIL? The GIL is global to the process
> (hence the name).
>
> void foobar(void)
> {
> PyGILState_STATE sta
On Sep 7, 2:04 pm, sturlamolden wrote:
> I just showed you how...
Modified the thread function to use these APIs, but the call to
PyGILState_Ensure() is not returning at all.
void *callPyFunction(void * arg)
{
// Method two to get function eval
long thridx=(long)arg;
printf("\n>my n
On 7 Sep, 07:59, ganesh wrote:
> No, I did not use GIL.
> -- For using GIL, do we need to initialize GIL at startup and destroy/
> finalize it at end?
> -- Are there any configuration & build related flags that I need to
> use to make this work?
>
> Please guide. Thanks.
I just showed you how...
> Did you remeber to acquire the GIL? The GIL is global to the process
> (hence the name).
No, I did not use GIL.
-- For using GIL, do we need to initialize GIL at startup and destroy/
finalize it at end?
-- Are there any configuration & build related flags that I need to
use to make this work?
P
> Did you remeber to acquire the GIL? The GIL is global to the process
No, I did not use GIL.
-- Why do we need to use GIL even though python is private to each
thread?
-- For using GIL, do we need to initialize GIL at startup and destroy/
finalize it at end?
-- With GIL, we are not achieiving co
On 7 Sep, 07:17, grbgooglefan wrote:
> Can we not use python interpreters even private to each multiple
> thread?
You can use multiple interpreters, but they share GIL. For example,
Python extension modules are DLLs and will be loaded only once for
each process - the OS makes sure of that. Since
On 7 Sep, 07:17, grbgooglefan wrote:
> What is best way to embed python in multi-threaded C++ application?
Did you remeber to acquire the GIL? The GIL is global to the process
(hence the name).
void foobar(void)
{
PyGILState_STATE state = PyGILState_Ensure();
/* Safe to use Python C A
Hi
I've a multi-threaded C++ program, in which I want to use embedded
python interpreter for each thread. I am using Python 2.6.2 on Linux
for this.
When I tried to embed python interpreter per thread, I got crash when
the threads were calling Python's C APIs.
Can we not use python interpreters
28 matches
Mail list logo
