[m-dev.] tabling I/O for retry

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Mar 2 16:46:36 AEDT 1999


On 02-Mar-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> Hi Fergus,
> 
> > A first go at implementing "retry" in mdb for procedures that do I/O
> > by memoizing the results of all the I/O operations.
> 
> A long-run kind of issue:  have you thought about reloading modified
> code during debugging?  One of the things I frequently do when
> debugging Prolog code is to run it under the debugger to figure out
> where a bug is, then correct it, reload it, and retry the erroneous
> goal.  If that works, I go on debugging, if not I look for other bugs.
> I would hope that eventually the Mercury debugger would support this
> style of debugging.
> 
> So the question is, is there any way to reconcile tabling IO
> operations for retry and reloading modified code?

When you unload the old code and load in the new code,
you will also get new copies of the static variables that hold
the tables.  So any call to a pragma_c I/O predicate in the
edited module will not be in the table.  Likewise, the code
you edit doesn't contain any I/O predicates itself, but
causes the I/O predicates in the library to be called in a different
order, or with new arguments, then the result will not be in the
table.  Whenever the result is not in the table, the system
will invoke the C code again to redo the I/O.  The system will
execute `IO = ++MR_io_counter;' to compute the new io__state.
This will ensure that *all subsequent I/O* is also redone,
since the new values of the IO state counter will not be
in the tables.

Conversely, if the newly loaded code doesn't contain any pragma
c_code that does I/O, and the calls to other I/O pragma c_code
procedures remain in the same order, with the same arguments,
then it will not redo any I/O.

Redoing all the I/O may not be the right thing to do,
since the state of the external world (including file pointers,
etc.) will not have been reset.  However, that seems like about
the closest approximation we can get.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.



More information about the developers mailing list