#2 Memory leak in the main loop #2

Отворено
отворено пре 3 година од jgart · 0 коментара
jgart коментирира пре 3 година

As I mentioned on the ROOL forum, the main program loop consists of PROCdisplay and PROCpostdisplay continuously calling each other, increasing the size of the BASIC stack each time. If the program is run for long enough, the BASIC stack will eventually consume all available memory.

This issue will take a fair amount of unpicking, if only because PROCdisplay gets called from roughly 150 different places in the program.

The first question to ask would be: "Is it worth fixing?" In the "Classic CAC" case the answer may well turn out to be "No". The memory leak is sufficiently slow that the program could run for days without failing (this would depend on the total memory available, of course). People who switch off their computers every night may never see the problem at all.

If you do wish to proceed, I suggest a rather simple main loop:

  1. Call PROCdisplay
  2. Wait for input from the user
  3. Call PROCpostdisplay (or possibly a new procedure PROCprocessUserInput)
  4. If "Quit program" has NOT been selected, go to 1.
  5. End program.

PROCdisplay needs to cleanly exit (rather than explicitly calling PROCpostdisplay).

Likewise, PROCpostdisplay must not call PROCdisplay (it currently does so over 30 times). Instead it should exit, so that PROCdisplay gets called from the main loop.

Unpicking the 100+ other calls to PROCdisplay could take a while: you would need to convert them all (the code as it stands probably isn't expecting PROCdisplay to exit).

This would also simplify the work needed to convert the main program to multitask under the Wimp at a later date ("Wait for input from user" would become "Call Wimp_Poll" as the Wimp handles all user interaction).

-- zedtoo-de Stuart Painting

As I mentioned on the ROOL forum, the main program loop consists of PROCdisplay and PROCpostdisplay continuously calling each other, increasing the size of the BASIC stack each time. If the program is run for long enough, the BASIC stack will eventually consume all available memory. This issue will take a fair amount of unpicking, if only because PROCdisplay gets called from roughly 150 different places in the program. The first question to ask would be: "Is it worth fixing?" In the "Classic CAC" case the answer may well turn out to be "No". The memory leak is sufficiently slow that the program could run for days without failing (this would depend on the total memory available, of course). People who switch off their computers every night may never see the problem at all. If you do wish to proceed, I suggest a rather simple main loop: 1. Call PROCdisplay 2. Wait for input from the user 3. Call PROCpostdisplay (or possibly a new procedure PROCprocessUserInput) 4. If "Quit program" has NOT been selected, go to 1. 5. End program. PROCdisplay needs to cleanly exit (rather than explicitly calling PROCpostdisplay). Likewise, PROCpostdisplay must *not* call PROCdisplay (it currently does so over 30 times). Instead it should exit, so that PROCdisplay gets called from the main loop. Unpicking the 100+ other calls to PROCdisplay could take a while: you would need to convert them all (the code as it stands probably isn't expecting PROCdisplay to exit). This would also simplify the work needed to convert the main program to multitask under the Wimp at a later date ("Wait for input from user" would become "Call Wimp_Poll" as the Wimp handles all user interaction). -- zedtoo-de Stuart Painting
Пријавите се да се прикључе у овом разговору.
Нема лабеле
Нема фазе
Нема одговорних
1 учесника
Учитавање...
Откажи
Сачувај
Још нема садржаја.