[m-dev.] for review: retry in trailing grades

[Zoltan Somogyi]

> > runtime/mercury_trail.h:
> > 	Add the new reason why the trail may be reset.
> 
> You should modify all the places in the Mercury distribution
> which switch on the trail reset reason --
> in particular extras/trailed_update/var.m and extras/clpr/clpr.m,
> but the may be others.

I updated extras/trailed_update/var.m and its test cases to treat retry as
an undo, and extras/references/scoped_update.m to report a runtime error
in the event of a retry, since I don't know what the proper thing to do is.
(Peter Schachte may wish to change that later.)

> I don't think it is a good idea to refer to individuals in error messages.
> I would change that to `fatal_error("Sorry, not implemented:
> copying of saved heap pointers")'; if you must mention Tyson by name,
> then it should go in a comment in the source, not in a runtime error
> message that our users might encounter.

Done.

> > +	    /* we do not yet compress the trail when doing gc */
> 
> That comment probably deserves an "XXX".

Done.

> Actually there is another case which should be documented there:
> 	- when throwing an exception (MR_exception)
> 
> There are a few other places where the trailing documentation has
> not been updated to reflect that we know support exceptions.
> I suppose that could be fixed as a separate change.

I will leave that to you. Actually, the implementation of trailing in
general should be a lot better documented.

> > +#ifdef	MR_USE_TRAIL
> > +		if (entry->MR_sle_maybe_trail >= 0) {
> > +			Word	ticket_counter;
> > +			Word	trail_ptr;
> > +
> > +			trail_ptr = MR_based_stackvar(this_frame,
> > +					entry->MR_sle_maybe_trail);
> > +			ticket_counter = MR_based_stackvar(this_frame,
> > +					entry->MR_sle_maybe_trail+1);
> > +			MR_reset_ticket(trail_ptr, MR_retry);
> > +			MR_discard_tickets_to(ticket_counter);
> > +		} else {
> > +			fatal_error("retry cannot restore the trail");
> > +		}
> > +#endif
> 
> Hmm... are the Mercury registers valid here?

No. However, the trail pointer and the ticket counter are global variables,
not registers, so they are valid.

> What will happen if the trail function tries to call back into Mercury code?

I thought that was not supposed to happen. Is my assumption wrong? If so,
what special Mercury registers can the trail handlers read, and what special
registers can the trail handlers write? (Trail handlers obviously cannot
access general purpose registers, because one cannot guarantee anything about
the contents of those registers when they are invoked.)

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------