SPFLite loop detection/not responding setting

Randall, based on your description, it seems like what is needed is a new feature in SPFLite to "register" names associated with networks, and then to "mark" those networks that are "slow". Then, there would need to be a flag you could set somewhere to say "ignore slow access time" or something.

Network names that SPFLite knew about would be either certain drive letters or UNC names like \\MYSERVER.

The idea you are presenting is more general than the macro Loop Check, but it seems like a useful concept to add, if George could find the right place to add it to the code. It would also take a fair amount of code to add the user-interface part needed to define drives and network paths, finding a place to store all the configuration data, etc. Since drive latency like this is a hardware attribute rather than "instance" related, perhaps this is data that should be stored in the Registry rather than SPFLite.CFG ?

George, what do you think?

R

George, I did Read The Fabulous Manual (just now), and it says,

If '-NOLOOP' appears as the command line, SPFLite will NOT activate it's normal loop detection logic.

Yes, that seems like it would do the trick. But, it is important to ask, is this the right trick to do?

What I mean is, if I'm not mistaken, your normal 'loop' detection doesn't really detect "loops", does it? It just detects a 'time-out' condition, some flag (or something) doesn't change or get reset (I am guessing here) within a certain timeout value (I think it's 10 seconds). Is that much correct, so far?

But, doesn't -NOLOOP disable all timeout testing? I see that as a possible problem, because there are three main causes of timeouts that I know. These are:

#1. Macro loops. These could be either long running loops, perhaps operating on a large file, or because of a macro bug.

#2. Macro popups asking for a user response. If the user takes longer than 10 seconds, SPFLite thinks that it has "timed out".

#3. Network I/O latency. Right now, Randall is having issue with this. It's no one's "fault", but is just how his network functions.

Now, if we use -NOLOOP to stop the 'not responding' #3 message, you are also going to suppress the #1 and #2 messages.

I think most people wouldn't care of #2 messages were always suppressed. Personally, I'd love it. But if #1 messages were suppressed, and a macro had a bug, it would be hard to manually intervene.


I have some recommendations that could help make it easier to manage these timeout situations. Comments invited.


1. Right now, timeout detection is either at the global level or on the macro level. I believe it could be useful to allow this at the primary command level also. That way, you wouldn't have to alter the properties of a desktop icon and restart to change things. Perhaps a command like this:

TIMEOUT [ ENABLE | DISABLE ]

If neither ENABLE or DISABLE were specified, the command would report on the current setting, as usual.


2. For macro calls that could cause a timeout, I recommend an SPFLite-provided "front-end" that would temporarily save then disable the timeout state, issue the normal function, then restore the timeout state. The only function that fits this - I think - is MSGBOX (and MSGBOXw). You'd make a new function SPF_MSGBOX which would take all the current parameters of the "real" MSGBOX, so all a macro writer would have to do is rename the function call.


3. For the network I/O latency, that would be more work. For Randall's scenario, the delay is caused by I/O to a network drive during read and write of an edit file. To quiet the warnings in this case, you'd have to somehow "front-end" your I/O of a file, so that you temporarily disabled the TIMEOUT test until the read or write operation were completed.


And yes, all this would require some work; how much, only you know. But, if this were possible (and, not too hard), it would be a better, more robust solution, instead of the current "blunt instrument" approach.


R

Further explanation is needed here.

There are two different loop checks.

First, for macros. Macros run in their own thread, and the timeout WAIT is part of the normal 'WAIT for thread completion'. It honors the macro function SPF_Loop_Check(ON|OFF) setting.

For all others in normal SPFLite execution, the 10 seconds is measured from the last keystroke to the final return to Windows marking completion of the Windows message. This testing is suspended internally by several routines such as during crash handling, during Printing, during reading or writing of any file > ~ 3 MB, during FIND/CHANGE ALL when the line count > 50,000, during some RUN and SUBMIT processing, and during Windows OPEN activity.

I had thought of just using the same suspend checking used by those routines for a new LOOPCHECK command, but then if any of those functions are used after a LOOPCHECK OFF command, we'd end up back with LOOPCHECK ON.

So a different way is needed. I just need to figure out the best way.

George

MUEH: That kind of approximation is really tricky to determine. A lot is based on the power of the system it's running on. A big difference between some 5 year old Pentium system with real hard drives and a newer i9 (or i10, i11 - whatever the latest is) with SSD drives. I doubt there is any simple way to determine what limit should be set.

George

Robert: Yes, I'm sure there's a way to come up with some kind of 'performance index' and then use it to determine an improved 'loop detected' interval.

But really, this is an editor, how many other editors are there that go to such levels to even detect loops, let alone loops based on measured performance standards.

Any effort here would truly be 'going down the garden path' to being a purely academic exercise.

George

Stefan: Main problem is that most of the 'suspend checking' activity is not matched by a corresponding 'resume checking' activity.

Every UI interaction eventually returns to Windows when complete. All the KB initiated stuff and mouse initiated stuff end up returning back through a common exit where 'resume checking' is issued - even if it was never set to 'suspend checking'.

A stack only works well if everyone uses it in pairs of requests.

Maybe I can create those 'pairs', TBD.

George