The reason USE_LAZY_CLOSE was originally put in the code was so that after loading a file, it would not be closed until another one was opened. That way, MDI code could call subroutines in the (still open) file.
I haven't followed how things have changed since I originally implemented that kludge. Ken On 9/15/2011 9:05 AM, Michael Haberler wrote: > v2.5_branch cannot properly recover from aborted oword procedures in external > ngc files. > > Symptom: aborted O-word subroutine leaves wrong file as current file, next > run command executes the wrong file. > > ---> please scroll to bottom to the decision item. > > Reproduce by: > > - have a ngc files like so: > > --- main.ngc --- > o<foo> call > m2 > ----- > > ---- foo.ngc: > o<foo> sub > #123 = [1/0] > o<foo> endsub > m2 > ---- > > > - Load main.ngc in Axis. This immediately runs the program for preview. > - Axis Interpreter aborts during preview run with Division by zero message > - clear the error + click the Run icon > - task runs program in task interpreter > - task interpreter hits Division by zero, aborts > - notice the filename in the Axis top level bar - changed to foo.ngc (!) > - Now hit 'run' again > - Axis will tell task to run 'foo.ngc' which doesnt do anything since its > just the sub definition > - Axis top level bar filename remains at foo.ngc . > - To get back to the starting state, one needs to open main.ngc again > > the sequence of events is quite involved: > - Axis loads main.ngc and executes it immediately for preview, hits Division > by zero > - Axis interpreter call_level remains at 1, _setup.filename now 'foo.ngc' BUT > taskfile (via emcstat()) still 'main.ngc' > - Axis toplevel bar shows 'main.ngc' because this reports the filename > obtained via emcstat > > - Task interpreter has at this point NOT executed main.ngc, therefore task's > perception of filename is 'main.ngc' as reflected in the axis toplevel bar > - now hit 'R' to run the program > - Task interpreter executes main.ngc, calls foo.ngc > - foo.ngc executes and foo.ngc is copied into task.file, which goes into > emcstat > - interpreter returns INTERP_ERROR while foo.ngc is open, and does NOT reset > the filename. > (_setup.call_level stays at 1 (!) and _setup.filename is still 'foo.ngc') > - Axis picks up foo.ngc through emcstat() and displays it in the toplevel bar > - On the subsequent Axis Run command, Task is told to run 'foo.ngc' which of > course doesnt do anything > > > The fix is obvious IMO: every time the interpreter fails, the call stack > needs to be unwound and the original filename restored; most of that code is > in Interp::reset(). Unfortunately the current approach to when reset() is > actually called is bit inconsistent (a.k.a 'grown over time'): > > 1. Failure of read() > 1.1 MDI,auto: errors are reset on the next task run which causes an > open()/close()/reset() sequence, not the interpreter itself (!) > > 2: Failure of execute() > 2.1 MDI: error reset by directly calling reset: line 259 > http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/rs274ngc/rs274ngc_pre.cc;h=8f186c513a22c8f0e41be8f84005c06dfae2a454;hb=df93a83e2b64c46dd540b29a84657247ed200d16#l1047 > 2.2 auto: error reset by task on next run as 2.2 > > note that states 1.1 and 2.1 are interpreter zombie states - it has a botched > callstack and wrong filename, and it cannot run, read() or execute() without > a previous reset(). That is surely a source for subtle different behaviour of > MDI and auto modes, which is a constant nuisance. Plus, the most obscure > USE_LAZY_CLOSE feature also gets in the way as it may prevent reset() from > being called. > > Hence there are two approaches to the problem: > > (1) Interpreter internal error reset: every time read(), or execute() fail, > the call stack is unwound. > (2) Error reset by using program: every time read() or execute() return > INTERP_ERROR, the *using program* will call the unwind method. > > (1) looks more robust to me - basically the invariant is 'interpreter erorred > - call stack is unwound' > (2) would leave the interpreter in the aborted state, enabling restart with > some clever code. It also means touching *all the calling code*, which is in > gcodemodule.cc and in sai/driver.c, and maybe some I didnt think of yet. > > I'll proceed and implement a fix along (1). If you have good reasons against > it, tell me now. > > I am also interested in hearing a really good justification for the > USE_LAZY_CLOSE 'feature'. Otherwise I think that should be removed. > 'performance' by avoiding a single close/open doesnt count - we're not > running Z80's anymore. > > > -Michael > > > > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- Kenneth Lerman 55 Main Street Newtown, CT 06470 203-426-3769 ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
