#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명
로딩중...
취소
저장
아직 콘텐츠가 없습니다.