These logs offer some glimpse into a crash that happens outside of Python. Is there anyway to get a similar log in Windows for crashes outside Python?
cptnwillard wrote the following on 12/4/2009 4:27 PM:
···
The last operation before the crash is the 0th entry. Thus, everything
that happens before "PyObject_Call" is interpretation of your Python
code which you typically do not care about.
Yes, wx.CallAfter is real neat for solving this type of problem. If it works for your design, you probably won't even need to restructure your existing threaded code much to get wx calls back into main thread.
Mike Driscoll wrote the following on 12/5/2009 3:06 AM:
···
the common "fix" is to wrap wxPython calls in wx.CallAfter (or one of the other methods already mentioned). So for the SetLabel example, it would be something
like this:
Thanks everyone who chimed in. It was a very helpful to get a handle on my issue.
CallAfter does seem to have managed those collisions for me. One of my threads is a timer thread which synchronizes between both some UI elements and some media playback elements, so the text labelling of the timer display seems to be that culprit.
In another thread I do some wx stuff, but it is confined to that thread I beleive, but I'll be taking a close look to ensure I don't have some other, less frequent crashes waiting to happen.
Thanks again.
Ross.
···
On 5-Dec-09, at 10:12 PM, Sam23 wrote:
Yes, wx.CallAfter is real neat for solving this type of problem. If it
works for your design, you probably won't even need to restructure your
existing threaded code much to get wx calls back into main thread.
Mike Driscoll wrote the following on 12/5/2009 3:06 AM:
the common "fix" is to wrap wxPython calls in wx.CallAfter (or one of the other methods already mentioned). So for the SetLabel example, it would be something
like this:
I learned about the rudiments of wx.CallAfter for multithreaded GUI projects from some conversations on this list, and it has been serving me well.
I have two questions related to that, and appropriate usage.
1) When doing some graphicsDC work, I am using wx.CallAfter for drawing commands with good success. I'm wondering it is appropriate to use wx.CallAfter() isolation for ALL cmds that interact with the DC or does it make sense only for one's which result in visible GUI changes.
ie. Do I need to CallAfter for all these dc interactions:
as that last call is the only one that effects a display change?
2) Let's say I have two GUI interacting routines DrawSomething() and MkDwgChanges() that are both in my app thread, and I occasionally call MkDwgChanges() from another thread.
I use wx.CallAfter() wrappers in my MkDwgChanges() routine so that it will not cause cross-thread collision crashes. But will those wx.CallAfter()'s cause any concerns when they are called within in the Thread0 execution? ie where they are not strictly needed because they are in the non-cross-threaded context with the wx GUI widgets in the same thread?
Thanks in advance for any help on understanding those Q's.
1) When doing some graphicsDC work, I am using wx.CallAfter for drawing commands with good success. I'm wondering it is appropriate to use wx.CallAfter() isolation for ALL cmds that interact with the DC or does it make sense only for one's which result in visible GUI changes.
yup - you never quote know what might cause problems -- AY wx cal should be in the main thread.
ie. Do I need to CallAfter for all these dc interactions:
usually those are done all together, in a single method, so it would be only one CallAfter to call that method.
In fact, particularly for dc.BeginDrawing, you realy wouldn't want all the other stuff called in separate events.
But will those wx.CallAfter()'s cause any concerns when they are called within in the Thread0 execution?
no -- CallAfter is not a thread-specific =call -- it is just a thread safe one. What it does is put an event on the event stack that will call your function when it reaches the top (bottom?) of the stack. There are often uses for it even within a single thread.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
On 1-Feb-10, at 11:45 PM, Christopher Barker wrote:
Ross wrote:
1) When doing some graphicsDC work, I am using wx.CallAfter for drawing commands with good success. I'm wondering it is appropriate to use wx.CallAfter() isolation for ALL cmds that interact with the DC or does it make sense only for one's which result in visible GUI changes.
yup - you never quote know what might cause problems -- AY wx cal should be in the main thread.
ie. Do I need to CallAfter for all these dc interactions:
wx.CallAfter(dc.BeginDrawing)
wx.CallAfter(dc.SetPen, wx.Pen('GREEN'))
wx.CallAfter(dc.DrawRectangle, bw, bh, RectWide, RectHi)
usually those are done all together, in a single method, so it would be only one CallAfter to call that method.
In fact, particularly for dc.BeginDrawing, you realy wouldn't want all the other stuff called in separate events.
But will those wx.CallAfter()'s cause any concerns when they are called within in the Thread0 execution?
no -- CallAfter is not a thread-specific =call -- it is just a thread safe one. What it does is put an event on the event stack that will call your function when it reaches the top (bottom?) of the stack. There are often uses for it even within a single thread.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception