-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Sam wrote:
> > I said I'd report when I know more, so here goes...
> >
> > The problem isn't with DefWindowProc at all (in fact
> > DefWindowProc doesn't do anything except default handling -
> > duh!). My apologies for being misleading.
>
> no problem. even checking the obvious is helpful in such
> cases :-)
>
> > The memory usage in the task manager thingee is useful, but
> > inherently misleading. It isn't a cache allocation thing or
> > anything like that, again sorry for being misleading.
> >
> > The problem is with the C-perl interface. The WindowMsgLoop
> > needs a good perl start, and end block:
> > dSP;
> > ENTER;
> > SAVETMPS;
> >
> > ....
> >
> > FREETMPS;
> > LEAVE;
>
> unfortunately not. WindowMsgLoop, itself, does not actually
> call the Perl interpreter: the various DoEvent_* functions
> performs the needed calls, and they all have (SAVE|FREE)TMPS
> blocks. I tried, just to give it a try, to make the changes
> you suggested to WindowMsgLoop, but nothing changes.
>
> > This is because it calls into the perl interpreter. The Dialog
> > XSUB doesn't need those blocks explicitly however because they
> > are added by xsubpp. However because the Dialog XSUB pretty much
> > never exits (and therefore calls FREETMPS) it accumulates TMPs.
> > There are (I believe) two ways to fix this:
> > 1/ make the dialog XSUB return after processing one message,
> > and call it from perl like
> > while( Win32::GUI::Dialog() ) {
> > }
>
> this is a good hint. unfortunately, it is not a solution.
> there is already a one-go Dialog XSUB, which is called
> DoEvents. I tried replacing the Dialog() call with this:
>
> 1 while ( Win32::GUI::DoEvents != -1 );
>
> and indeed, there is no apparent memory leak!
>
> BUT, the processor is busy at 100% while the Perl
> program runs: this is because the while loop, even if
> 'void', does consume CPU time. too bad :-(
That's because it uses PeekMessage, which returns immediately
regardless of whether or not there are any messages waiting.
> BUT, this is a first approach to a possible solution,
> because it seems to isolate the problem in the Dialog()
> XSUB. I'll try to debug it and see if I can understand
> something more.
>
> > 2/ give the Dialog XSUB an explicit block around the perl
> > interpreter calls it makes. I believe that this will work
> > fine, but I haven't tested it. I implemented (1) in my copy
> > of win32::GUI.
>
> what do you mean by 'interpreter calls' here?
>
> > NB:
> > It may be necessary to add blocks in other places (in fact
> > I'm sure of it), but this is the only problem I am aware of.
> > I can't create and distribute a patch on work time, but in my own
> > time (of which I have very little unfortunately) I will create
> > a patch for 0.0.502, and send this to Aldo, if he so desires.
>
> please do so if you can :-)
>
>
> cheers,
> Aldo
>
> __END__
> $_=q,just perl,,s, , another ,,s,$, hacker,,print;
>
>
>
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQA/AwUBOlwquJsRND2Z+TaWEQJEPwCeLjIAiDb1DHzs8woIpcIpaV7u3JEAnR4G
38Dh5N9HX44Guqr612WBFf6Y
=mvOy
-----END PGP SIGNATURE-----
Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz
