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 :-(

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;



Reply via email to