Activate event handler and SetWindowPos()

wxPython Users
1

Setting breakpoints will take some time because right now
we are just using the wxPython DLL and not compiling anything
directly. However, I don't think I have to go that far.

The lockup happens upon the actual call to SetWindowPos from
C++. The function has the correct effect because the other application
does pop up, but it leaves the wxPython app hanging after that. So
at first glance it doesn't appear to be a problem with the
interpreter lock.

In fact, the application passes control back and forth from Python
to C++ repeatedly, but all the code is (and always will be) executed
on a single thread.

···

-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Monday, February 17, 2003 5:49 PM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] Activate event handler and SetWindowPos()

Some more questions:

Does it happen when you call SetWindowPos or when you are coming back
and reactivating your app? If the former try putting a breakpoint in
wxPyCallback::EventThunker just before the the call to SetWindowPos
happens. Does it get stuck on the call to wxPyBeginBlockThreads? If so
then you've got a problem dealing with the Python global interpreter
lock as you already have the GIL and it is blocking waiting for it to be
released, resulting in a deadlock.

The general rule is that any calls from Python to native code need to be
wrapped in calls to wxPyBeginAllowThreads and wxPyEndAllowThreads.
Calls from native code back to Python (event handlers, or even anything
that can manipulate PyObjects) needs to be wrapped in calls to
wxPyBeginBlockThreads and wxPyEndBlockThreads. This is all handled
automatically within wxPython, but by embedding in a C++ app you are
adding a new wrinkle and need to take care to treat the GIL right.

Does this help?

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

________________________________________________________________________
This email has been scanned for all viruses and found to be virus free. If you have questions regarding this scanning please visit the Information Services area of http://home.vitalimages.com
________________________________________________________________________

2

Jeff Kotula wrote:

Setting breakpoints will take some time because right now
we are just using the wxPython DLL and not compiling anything
directly. However, I don't think I have to go that far.

The lockup happens upon the actual call to SetWindowPos from
C++. The function has the correct effect because the other application
does pop up, but it leaves the wxPython app hanging after that. So
at first glance it doesn't appear to be a problem with the
interpreter lock.

It still could be the problem. The interpreter lock is local to the process so even if the other app is workign fine the fact that the wxPython app has locked up is a good sign that it is deadlocked on the GIL, especially since it happens when you do something that causes control to try and aquire the lock and reenter Python for the event handler.

In fact, the application passes control back and forth from Python
to C++ repeatedly, but all the code is (and always will be) executed
on a single thread.

It doesn't matter. If you are using a Python (and wxPython) that is compiled for threading then you must use the functions/macros that deal with the GIL even if you have only one thread.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!