wierdness with pythonwin dialogs, threads & refcounts

[Dave Kirby]

On Thu, 17 Jun 1999 09:21:51 -0500, "Gordon McMillan"
<gmcm at hypernet.com> wrote:

>Dave Kirby writes:
> 
>> I have found strange behaviour (strange to me at least) when
>> creating a pythonwin dialog on a separate thread created using the
>> standard python thread module.  The dialog object is never deleted
>> since the thread is keeping references to it. 
>> [example snipped]
>
>First, there's no incompatibility with the thread module in 
>Pythonwin. 
>
>Second, you should use threading.py, not the low level thread module 
>(which is very, very primitive). Or you can use 
>win32process.beginthreadex which is a wrapper around MFC threads. 
>This lets you manipulate priorities. (As of a couple years ago, there 
>was a small memory leak involved with using MFC threads, however).

I have just tried both the threading.py and beginthreadex with the
same results - vis:

[carrying on from the previous example]
>>> import win32process
>>> test()
Edit text changed!
refs: 2
>>> x = win32process.beginthreadex( None, 10000, test, (), 0 )
>>> refs: 6
>>> import threading
>>> thread = threading.Thread(target = test)
>>> thread.start()
>>> refs: 6

Again the refcount is 6 when test is run from a separate thread, but 2
when run in the main thread. 


>
>As for the source of your questions - without doing things in a debug 
>build of python / Pythonwin, it's almost impossible to tell what's 
>going on, or even if there really is a problem.
>
>Using sys.getrefcount increments the refcount. Printing something in 
>the interactive interp binds the thing to a var named "_" (to 
>optimize looking at it again). Printing to stdout in Pythonwin 
>involves all kinds of hidden manipulations.
>
>If you want to know whether you're leaking TestDialogs you could code 
>a loop that creates threading.Thread's that show a TestDialog and 
>then joins the Thread. Run it for as many iterations as you can 
>stand, and watch the process in TaskManager.

I am pretty sure there is a real problem here. Whatever the hidden
manipulations are it shouldnt make any difference which thread it is
running in. I discovered this problem because the __del__ method was
not being called for the dialog class in the program I am writing.
When I moved it to the main thread it was destroyed ok. 

I will play around with this some more and try to narrow it down
further, but I am not intimate with either the internals of pythonwin
or Windows threads, so don't hold your breath.  One thought that did
occur to me is that the python thread/threading modules and
win32process.beginthreadex are all creating worker threads so there is
no message processing being done to clean up the dialog when it is
closed. I will test this hypothesis as soon as I have figured out how
to create GUI threads in pythonwin.

Regards,

	Dave K