[mercury-users] Way to exit immediately from a Mercury program?

[Jonathan Morgan]

On 4/27/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
>
> On Thu, 27 Apr 2006, Jonathan Morgan wrote:
>
> > On 4/26/06, Julien Fischer <juliensf at cs.mu.oz.au> wrote:
> > > That's what we do in the GLUT binding (see
> > > extras/graphics/mercury_glut/glut.m), defining exit similar to the
> > > following:
> > >
> > >         :- pragma foreign_proc("C",
> > >                 exit(_IO0::di, _IO::uo),
> > >                 [will_not_call_mercury, promise_pure],
> > >         "
> > >                 exit(mercury_runtime_terminate());
> > >         ").
> >
> > Is it necessary to terminate the runtime?  What happens if you don't?
>
> Finalizers may not be run, your program may return the wrong exit status
> to the OS, trace counts or deep profiles may not be written etc.

All of which can cause problems.  Another thought: is there a similar
termination function for the IL/Java backends?

> > > It should be noted, among other things, that terminating a program this
> > > way will stuff up the deep profiler (and most probably isn't that great
> > > if you wish to use the debugger either).
> >
> > Does this mean that these tools can't be used usefully used with
> > various GUI toolkits? (I don't think GLUT is the only one that is
> > likely to need such treatment).
>
> GLUT is something of a special case because glutMainLoop() never returns and
> there isn't a quit event processing event or similar to break out of it
> cleanly.  Throwing an exception from within one of the callbacks and catch it
> at the top-level seems to work (at least on x86-linux) but I didn't do that
> when I wrote it because:
>
> (1) throwing exceptions across the C interface isn't recommended
>
> (2) it wasn't clear how GLUT would react if you then tried to re-enter the
> main loop (from the look of the source code it would probably be
> fine).

I'm interested because Gtk+ also has a main loop that is never
returned from.  As I currently have it (which is the same as the C
Gtk+ way of handling it) the Gtk quit must be called from the (main
window) destroy event, otherwise the application will never terminate.
 I have not done any calling of Mercury termination functions, and
it's not entirely clear to me where such calls should go, and whether
the exit status works nicely with Gtk's cleanup functions.

> The debugger is limited with most GUI toolkits anyway because it cannot see
> over the C interface, e.g. if you're in a (Mercury) callback the stack trace
> will only go back as far as the thing the entry to the Mercury code.

Granted.

Jon

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------