#2 Memory leak in the main loop #2

开启中
jgart3 年之前创建 · 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 名参与者
正在加载...
取消
保存
这个人很懒,什么都没留下。