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

[Julien Fischer]

On Thu, 27 Apr 2006, Jonathan Morgan wrote:

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

For the Java backend no.  I'm not sure what the IL backend does.

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

IIRC, gtk has functions that allow you to run one (or a fixed number of)
iteration(s) of the main loop.  It might be possible to bypass gtk's main
loop and implement your own at the Mercury level.

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