#2 Memory leak in the main loop #2

開啟中
jgart3 年之前創建 · 0 條評論

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 參與者
正在加載...
取消
保存
尚未有任何內容