[MUD-Dev] Re: atomic functions

[Felix A. Croes]

J C Lawrence <claw at under.engr.sgi.com> wrote:

>[...]
> Ahh!  Light dawns!  You are taking about exception models, not locking 
> or commit models!
>
> Ahhhhhhh, I see.  Then yes, in that guise atomic functions as you term 
> them have a very definite and valuable use.  Nice idea.  
>
> However it also assumes (but does not require) that an atomic function
> has only one success state, and possibly many failure states.  Or, to
> use the exception model, what if some exception forms are are
> acceptable?
>
> My language construction uses exceptions heavily.  In fact an
> exception is the default (only) return path.  An exception encludes
> specifics on where it was raised, and may be bound with other
> code-supplied data sets.  An ERR_OKAY exception is thus the normal
> return with any return code being accessably by querying the exception 
> for its bound data set, and with ERR_<anything_else> being the error
> cases (with possible bound data sets).

I mean to have atomic functions in addition to my existing exception
model.  So, if an error occurs in an atomic function, and the error
is caught within the function, handle it in the usual way.  If the
error is not caught within the function, rollback changes and stack
frame to the entry point of the function, and throw the error again
from there.

Complications arise if you want to pass along arbitrary data with the
error, and arrays are shared in your system (as they are in mine).
The data could then include information which also exists in a state
where no changes have occurred.  My solution is not to allow the
passing along of data in this case, apart from the information
contained in the errorcode itself.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.