[mercury-users] Exceptions and unique modes

[Peter Ross]

On Thu, Feb 15, 2001 at 03:52:30PM +1100, Fergus Henderson wrote:
> This issue has been discussed before.  Unfortunately the mailing list
> search facility is broken right now (we're in the process of moving it
> to a new machine, since the old one seems to be suffering from hardware
> problems), so I can't give you an exact reference.
> 
> On 14-Feb-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> > >From Peter Ross on 14/02/2001 16:23:43
> > > 
> > > Currently the only unique object which can be used with exceptions is an
> > > io__state, and it makes the assumption that the io__state you get back
> > > when an exception is thrown is the one that existed at the time of the
> > > exception.
> 
> No, it doesn't.  The io__state that you get back when an exception is
> thrown will in general be different from the one that existed at the
> time the exception was thrown.  If any I/O has been done when the
> exception has been thrown, then the state that you get back will
> include all the side effects of whatever I/O has been done.
> 

What I was trying to say is that the io__state you get back when you
catch the following exception is IO1.

    do_some_io(IO0, IO1),
    throw(exception)

Which is what I think you are saying as well.

> > I think that's an oversight: I don't see why try_io has to be io__state
> > specific: surely it could be generalised to any unique type.
> 
> No, it can't.  The problem is that for an arbitrary type there is no
> guarantee that there is any valid value of that type around when the
> exception is thrown.  For `io__state', we know that there will always
> be a valid state of the world at any point in the computation.
> We can't guarantee that for arbitrary types.
> 
> > > This would suggest that to be consistent with the way io__state is
> > > handled,
> > > we guarantee that after an exception that the state of a unique object
> > > is that at the point where the exception is thrown.
> > > 
> > > Thoughts?
> > 
> > The exception mechanism should certainly not change the state of unique
> > objects.
> 
> The exception mechanism itself doesn't change the state of unique objects.
> But the code which is wrapped inside an exception handler could,
> if we allowed it have a `di, uo' mode.
> 
But where do we get the initial state of the unique object from?
If you have some block of code which uses a threaded unique object, then
you will have to protect every call with an exception handler just so
that you can throw the correct unique object.  Yuck!

I am really starting to think that threaded unique objects, should be
treated specially in the language, maybe with some sort of special
syntax which allowed you to use one name to talk about a threaded unique
object and the compiler was smart enough to do a source-to-source
transformation which made this all declarative.

The main reason you want to get a handle back on a unique object is so
that you can clean up the resources associated with that object.  If we
had a special syntax for threaded unique objects we could use something
like

create_unique_object(!Obj)
protect (!Obj, destructor_for_unique_object),
{
    block or higher order code which uses unique object
}

If an exception was thrown in the protect block then
destructor_for_unique_object is called with the *current* state of the
unique object otherwise at the end of the block
destructor_for_unique_object would be called.  This is, I believe, what
unwind-protect does in LISP.

> > I wonder if we could arrange things so that old pointers to unique objects
> > were still valid in the operational sense that they continue to point to
> > those objects;
> 
> Code which has a `di' mode is allowed to completely clobber the
> storage for the `di'-moded argument.  There's no way to guarantee that
> it will contain anything meaningful when such code throws an exception.
> For example, the compiler may have applied compile-time garbage collection
> to explicitly deallocate the old storage, and then reused it to hold
> a value of a completely different type.
> 
> The best thing to do is to either (a) make a copy of the unique object
> before running the code which might throw an exception
> or (b) use `mdi' modes and trailing.
> 
Exceptions are by their very nature exceptional, but if you want to use
them with unique modes then you have to add the possibly expensive
operations of copying or trailing, for the rare case an exception is thrown.

Now when writing a high-performance, robust server two features are
key: unique modes for performace and exceptions for robustness.  This is
why I think we need to come up with a semantics for exceptions in the
presence of unique objects which is cheap to use.  Unfortunately I don't
have any good ideas either, that is why my head hurts!

Anyway I am just throwing ideas in the air to see what people think.

Pete
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------