AcquireThreadLock - bug? future?
Hi. I have small problem with multithreading and need help to solve it. I have dll written in managed C++. Within dll I have class that has static function. I'd like to call this function from a few threads from python. I failed to do this. Calling function staled and this is a stack dump from debugger ( of my program ) python.runtime.dll!Python.Runtime.PythonEngine.AcquireThreadLock() + 0x40 bytes python.runtime.dll!Python.Runtime.MethodBinder.Invoke(int inst = 11793552, int args = 9900080, int kw = 0) + 0xf0 bytes python.runtime.dll!Python.Runtime.MethodObject.Invoke(int target = 11793552, int args = 9900080, int kw = 0) + 0x25 bytes python.runtime.dll!Python.Runtime.MethodBinding.tp_call(int ob = 11794928, int args = 9900080, int kw = 0) + 0x137 bytes I don't understand: 1. Why Python.Net tries to acquire thread lock, while calling function ? I am possible to call get property from a few threads. From managed C++ point of view ( I could be wrong here ) getting value of property it is just syntax sugaring for get_??? call. I want to say that if I able to call "get property" from a few threads I should be able to call function from a few threads. 2. Why at all Python.Net tries to synchronize function calls? I can modify and compile source code of Python.Net, but I know to little about reasons of calling AcquireThreadLock. Thanks for help Roman
Essentially the engine needs to own the thread lock in order to call Python C API functions. When a (managed) method is called, the MethodBinder: - releases the lock (so that other threads could potentially run) - calls the managed method - re-acquires the lock after the call (because it needs to use the C API again to Pythonify the result, etc.) So it sounds like some thread is unable to re-acquire the lock. This gets tricky _really_ quickly, because you can actually be calling a managed object that may later call back into Python code... etc. Note that this doesn't happen for properties, because I arbitrarily decided that since properties are expected to to be lightweight that it wasn't worth the overhead ;) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: pythondotnet-bounces@python.org [mailto:pythondotnet-bounces@python.org]On Behalf Of Roman Yakovenko Sent: Monday, March 14, 2005 1:24 AM To: pythondotnet@python.org Subject: [Python.NET] AcquireThreadLock - bug? future?
Hi. I have small problem with multithreading and need help to solve it. I have dll written in managed C++. Within dll I have class that has static function. I'd like to call this function from a few threads from python. I failed to do this. Calling function staled and this is a stack dump from debugger ( of my program )
python.runtime.dll!Python.Runtime.PythonEngine.AcquireThreadLock() + 0x40 bytes
python.runtime.dll!Python.Runtime.MethodBinder.Invoke(int inst = 11793552, int args = 9900080, int kw = 0) + 0xf0 bytes
python.runtime.dll!Python.Runtime.MethodObject.Invoke(int target = 11793552, int args = 9900080, int kw = 0) + 0x25 bytes
python.runtime.dll!Python.Runtime.MethodBinding.tp_call(int ob = 11794928, int args = 9900080, int kw = 0) + 0x137 bytes
I don't understand: 1. Why Python.Net tries to acquire thread lock, while calling function ? I am possible to call get property from a few threads. From managed C++ point of view ( I could be wrong here ) getting value of property it is just syntax sugaring for get_??? call. I want to say that if I able to call "get property" from a few threads I should be able to call function from a few threads. 2. Why at all Python.Net tries to synchronize function calls?
I can modify and compile source code of Python.Net, but I know to little about reasons of calling AcquireThreadLock.
Thanks for help
Roman _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
On Mon, 14 Mar 2005 07:07:31 -0500, Brian Lloyd <brian@zope.com> wrote:
Essentially the engine needs to own the thread lock in order to call Python C API functions. When a (managed) method is called, the MethodBinder:
- releases the lock (so that other threads could potentially run)
- calls the managed method
- re-acquires the lock after the call (because it needs to use the C API again to Pythonify the result, etc.)
So it sounds like some thread is unable to re-acquire the lock. This gets tricky _really_ quickly, because you can actually be calling a managed object that may later call back into Python code... etc.
Note that this doesn't happen for properties, because I arbitrarily decided that since properties are expected to to be lightweight that it wasn't worth the overhead ;)
I never wrote programs using Python C API. I think this is the first reason why I don't understand why I should acquire thread lock Pythonify the result. I definitely will read python manuals. An other thing that I understand from your answer is that if I wrote property that takes time ( for example server.IsConnected - makes ping to the remote server ) I will run into some undefined behaviour ? I don't have enough knowledge. Could you propose some solution ? If you need more information I can debug application.
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: pythondotnet-bounces@python.org [mailto:pythondotnet-bounces@python.org]On Behalf Of Roman Yakovenko Sent: Monday, March 14, 2005 1:24 AM To: pythondotnet@python.org Subject: [Python.NET] AcquireThreadLock - bug? future?
Hi. I have small problem with multithreading and need help to solve it. I have dll written in managed C++. Within dll I have class that has static function. I'd like to call this function from a few threads from python. I failed to do this. Calling function staled and this is a stack dump from debugger ( of my program )
python.runtime.dll!Python.Runtime.PythonEngine.AcquireThreadLock() + 0x40 bytes
python.runtime.dll!Python.Runtime.MethodBinder.Invoke(int inst = 11793552, int args = 9900080, int kw = 0) + 0xf0 bytes
python.runtime.dll!Python.Runtime.MethodObject.Invoke(int target = 11793552, int args = 9900080, int kw = 0) + 0x25 bytes
python.runtime.dll!Python.Runtime.MethodBinding.tp_call(int ob = 11794928, int args = 9900080, int kw = 0) + 0x137 bytes
I don't understand: 1. Why Python.Net tries to acquire thread lock, while calling function ? I am possible to call get property from a few threads. From managed C++ point of view ( I could be wrong here ) getting value of property it is just syntax sugaring for get_??? call. I want to say that if I able to call "get property" from a few threads I should be able to call function from a few threads. 2. Why at all Python.Net tries to synchronize function calls?
I can modify and compile source code of Python.Net, but I know to little about reasons of calling AcquireThreadLock.
Thanks for help
Roman _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Greetings I think this may be tye reason why I can successfuly cal any property from Zope, but any function call except constructor hangs the instance Can there be some option to treat methods like properties also, so product become usable from Zope? Thanks Alexander ----- Original Message ----- From: "Brian Lloyd" <brian@zope.com> To: "Roman Yakovenko" <roman.yakovenko@gmail.com>; <pythondotnet@python.org> Sent: Monday, March 14, 2005 2:07 PM Subject: RE: [Python.NET] AcquireThreadLock - bug? future?
Essentially the engine needs to own the thread lock in order to call Python C API functions. When a (managed) method is called, the MethodBinder:
- releases the lock (so that other threads could potentially run)
- calls the managed method
- re-acquires the lock after the call (because it needs to use the C API again to Pythonify the result, etc.)
So it sounds like some thread is unable to re-acquire the lock. This gets tricky _really_ quickly, because you can actually be calling a managed object that may later call back into Python code... etc.
Note that this doesn't happen for properties, because I arbitrarily decided that since properties are expected to to be lightweight that it wasn't worth the overhead ;)
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: pythondotnet-bounces@python.org [mailto:pythondotnet-bounces@python.org]On Behalf Of Roman Yakovenko Sent: Monday, March 14, 2005 1:24 AM To: pythondotnet@python.org Subject: [Python.NET] AcquireThreadLock - bug? future?
Hi. I have small problem with multithreading and need help to solve it. I have dll written in managed C++. Within dll I have class that has static function. I'd like to call this function from a few threads from python. I failed to do this. Calling function staled and this is a stack dump from debugger ( of my program )
python.runtime.dll!Python.Runtime.PythonEngine.AcquireThreadLock() + 0x40 bytes
python.runtime.dll!Python.Runtime.MethodBinder.Invoke(int inst = 11793552, int args = 9900080, int kw = 0) + 0xf0 bytes
python.runtime.dll!Python.Runtime.MethodObject.Invoke(int target = 11793552, int args = 9900080, int kw = 0) + 0x25 bytes
python.runtime.dll!Python.Runtime.MethodBinding.tp_call(int ob = 11794928, int args = 9900080, int kw = 0) + 0x137 bytes
I don't understand: 1. Why Python.Net tries to acquire thread lock, while calling function ? I am possible to call get property from a few threads. From managed C++ point of view ( I could be wrong here ) getting value of property it is just syntax sugaring for get_??? call. I want to say that if I able to call "get property" from a few threads I should be able to call function from a few threads. 2. Why at all Python.Net tries to synchronize function calls?
I can modify and compile source code of Python.Net, but I know to little about reasons of calling AcquireThreadLock.
Thanks for help
Roman _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
participants (3)
-
bksasha＠zahav.net.il -
Brian Lloyd -
Roman Yakovenko