The LOOP DETECTED Window

Stefan
Administrator

Posts: 990

The LOOP DETECTED Window Jan 22, 2021 6:59:18 GMT -5

Quote

Post by Stefan on Jan 22, 2021 6:59:18 GMT -5

George,

At present, if all is well and SPFLIte just has a lot of work to do, pressing the <OK> resumes the process.

If the user suspects that there's a problem and SPFLIte may be looping out of control, pressing the <CANCEL> button kills the application, with certain data loss.

I'm only guessing here, but the fact that the pop-up window contains information like the last commands entered and a trace of modules executed, suggests that you have the ability to execute some code in there that is SPFLite-aware to collect such stats.

1st suggestion:

It would be useful if the currently executing primary command or line command were mentioned here, together with the line number (as perceived by the user) of the line being processed.

My rationale is that it allows the user to click <OK> and when/if the dialog pops up again see if the process has actually made progress or is in a tight loop and needs <CANCEL>.

I'm also guessing, but given that <OK> resumes the loop without any issue, why could <CANCEL> not do the same thing, but with a twist?

2nd suggestion:

What if pressing <CANCEL> were to (1) set a global variable accessible to all SPFLite modules/threads and then (2) resume the loop the same way <OK> does?

I appreciate this next bit will make you groan, but...

you could check inside each loop if the CANCEL_Flag is set and effectively 'LEAVE' (EXIT FOR, EXIT EXIT WHILE, etc) that loop.

Called routines can pass back suitable return code, or the caller could check the flag themselves.

You'd pop out of whatever loop nesting you were in and eventually whatever primary or line command was being aborted.

The screen display can check the CANCEL_FLag too and present an appropriate COMMAND ABORTED message when refreshing the display.

All the user has lost is the proceeds of the command that was running. The clean up may require little more than an UNDO.

Data in all other open tabs is safe.

3rd suggestion:

Would it be possible to add a third button to the dialog that does kill SPFLite altogether - useful as a safety parachute.

You might then have <OK> (although I'd prefer <CONTINUE>). <ABORT Command> for 2nd suggestion and <TERMINATE> for Kill me now!

It happens rarely, and the loop-exit effort would be substantial. So I understand if you don't consider it worthwhile.

Last Edit: Jan 22, 2021 7:06:53 GMT -5 by Stefan

George
Administrator

Posts: 4,056

The LOOP DETECTED Window Jan 22, 2021 12:19:10 GMT -5

Quote

Post by George on Jan 22, 2021 12:19:10 GMT -5

Stefan: The loop intercept is not capable of doing very much in the way of gracefully terminating the loop. Basically, the module trace is not done by 100% of all SUB/FUNCTION/METHODS, it requires some code on entry and on Exit from the module and it would add way too much overhead to add it to every single module. So it is only done on larger code blocks.

But mainly, even if you could pin it down to a single module's code, what can you do? As you said, set a global flag and modify every possible program loop to constantly check the flag. OK, the loop detects the flag, what can it do? Just exit the FOR/NEXT DO/LOOP? Not too safe. Exit the SUB/FUNCTION itself? With work undone? Pass back some error? SUBS can't do that. FUNCTIONS already are expected to pass 'something' back (how to add some 2nd return value), are all callers now expected to check the return from every function they call?

Even back in ZOS days this was hard. Functions had to provide FRR's (Functional Recovery Routines) which were custom code written to handle failures in the original module.

Trying to exit gracefully is extremely difficult.

George

Stefan
Administrator

Posts: 990

The LOOP DETECTED Window Jan 23, 2021 12:43:06 GMT -5

Quote

Post by Stefan on Jan 23, 2021 12:43:06 GMT -5

I hear what you're saying,... but I wonder if either parts of the easy bit is possible..

The eas(ier) bit

Part 1 - provide user-friendly data for a GO/NOGO decision

As a user, the module trace doesn't help me decide whether to click <OK> or <CANCEL>.

But an indication of which data line (number) was being processed would allow the user to make an informed decision about whether to click <OK> or <CANCEL>

e.g. "I'll let it continue once or twice and then kill it if it is still on the same line".

Part 2 - tailor the loop limit

Most of the time, the pop-up dialog appears because SPFLite has simply not yet finished in doing what was asked, eg. there are thousands of lines to process.

Question. Do you have control over the 'limit' that triggers the trap?

If so, It might be useful if the limit were higher for files with more lines or for complex functions that require more statements to be executed to do their 'thing'.

eg: Anything that works with 'Excluded' lines can run into the loop limit if that are many small blocks or individual excluded lines, like FLIP X

The hard bit - disgracefully return from a loop.

Disclaimer: I couldn't find anything to tell me how the Loop Detection is triggered in PowerBasic, so what follows may be right or wrong.

I figure that technically, NO error/Abend has occurred (but I maybe PowerBasic raises one for the loop detection?).

We simply arrived at the pop-up window point because some arbitrary instruction count or time limit has been reached.

At best, the interrupt came at the end of a completed PowerBasic statement, at worst it happened 'mid statement'.
But we'll be resuming the code anyway after setting a flag, so no drama.

So I contend that the situation is not really comparable to being in an ESTAE or an FRR.

The purpose here is not to create a fool-proof trap for all eventualities that tidies up after itself, but to preserve all other tabs, even if the current tab's integrity is lost.

I have a file comparison/deduplication program that operates against all files in given folders.

I grant you the codebase is nowhere near the scale of SPFLite, but there can be thousands of files in the folders and subfolders, so I wanted a "user cancel" option.

Essentially I just added the USERCANCEL condition to each of the major 'key' loops, (eg: DO WHILE <usual-conditions> & NOT USERCANCEL).

By 'key' I mean those where the code is expected to spend most of its time or that are especially sensitive to external influence (eg data might not be as expected).

It simply terminates each loop earlier (or prevents it all together).

Subroutines and functions pass back results as normal, leaving it up to the caller's USERCANCEL trap handling to propagate the interrupt process 'up-the line'.

It's not a graceful solution, but effective regardless of how deeply nested or in which subroutine(s) the 'trigger' occurs.

Thinking about how to deal with the global flag in the SPFLite code, I reckon you can probably limit your intervention to PRIMARY commands, or maybe brand new code during a "bedding-in" phase.
I can't think of any Line commands that would cause a mega-loop.
The loop-trap for MACROS is fine as-is, given that users who write macros are generally 'sufficiently experienced' to know how to deal with loops.

The code resurfaces as if the command had completed, but with a prominent "COMMAND ABORTED" warning message (perhaps in a pop-up dialog rather than just in the msg area top right).

It doesn't matter if it's messy and leaves a line 'half-done'.

And it will definitely leave the file 'half-done', but data in other tabs is secure and the user has options from here:

- Try an UNDO and check the file's integrity.

- Use CREATE to save the file under another name and then use DIFF later to see what can be salvaged.

- SAVE any changed data in other tabs and then drop and restart SPFLite in an orderly fashion.

At least we've only damaged one Edit tab and not all of them. Most of the day's effort and data is retained.

I think that compares favourably to the current alternative which

- kills SPFLite dead

- loses changed data from all open tabs

- doesn't update the FILELISTs

- and probably not the CFG file either, although I haven't tested that bit.

Last Edit: Jan 23, 2021 12:56:34 GMT -5 by Stefan

George
Administrator

Posts: 4,056

The LOOP DETECTED Window Jan 23, 2021 13:42:27 GMT -5

Quote

Post by George on Jan 23, 2021 13:42:27 GMT -5

The loop detection in SPFLite is quite simple. We start a thread that does nothing but wake up every 1 seconds.

There is a global LoopCtr.

The counter is reset every time an Attention is triggered (Enter, PFK, etc), when the command finishes and returns back to the KB/MOUSE handler for the next interaction, the counter is reset to -1 (Off)

If the thread wakes, and the counter is not -1, it increments it. When it hits 10, it triggers a unique Loop Exception, and the pop-up occurs. There are also tweaks to turn off loop detection for large file Reads/writes. As well the limits are increased for large loaded files (these may need adjusting since SPFLite now can handle much larger files)

PB does have TRY/CATCH/FINALLY/END TRY blocks, SPFLite uses them a lot. But how does that help? So we wrap every routine in one, what does the CATCH block do? THAT is just one problem.

The other is having to create multiple TRY blocks in many of the functions. Many routines do short-circuit exits from the module, I don't fancy trying to figure out how/where to insert EXIT or END TRY statements so we don't exit with an active TRY block running. Or attempt an EXIT TRY when one isn't active. I don't feel like exploring the "what happens".

The best solution is to fix or prevent crashes in the first place. Designing and implementing (let alone testing) a bunch of recovery routines is, to me, a waste of time.

Stefan, the diagnostics in the Pop-Up were never designed for the user, they're for me. (and they've proved to be only minimally useful at best) As to displaying what line # was involved? Well nigh impossible. What is the line involved? Is it the current cursor line? Is it the current line being processed by Find/Change? Is it the line(s) being expanded/collapsed by some Exclude/Show function? Or Split/Join, or ... or ...

George