|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000336||mercury||Bug||public||2014-06-20 10:30||2015-11-02 11:41|
|Target Version||15.11||Fixed in Version|
|Summary||0000336: java programs do not wait for all threads to finish|
|Description||The program terminates soon after the main thread exits, even if other threads are running.|
|Tags||No tags attached.|
I'm about to do some work on the Java concurrency stuff for MCit. So I'll look at this at the same time.
The behaviour of multi-threaded programs when the main thread terminates needs to be specified
somewhere, reference manual(?) or in the comment at the head of thread.m. Furthermore the behaviour
should be consistent across backends.
What should be the behavior if an error is raised. For example:
+ The exit status is set to non-zero (I think it should wait).
+ An exception is uncaught in main/2 (Should it exit immediately?)
+ Can a mercury program call abort() like one can in C?
+ An internal error (in Mercury) (it should exit immediately).
> What should be the behavior if an error is raised. For example:
> + The exit status is set to non-zero (I think it should wait).
Yes. It just sets a global variable.
> + An exception is uncaught in main/2 (Should it exit immediately?)
I think so.
> + Can a mercury program call abort() like one can in C?
Yes. Mercury can't prevent anyone doing so anyway.
> + An internal error (in Mercury) (it should exit immediately).
Yes. We can't continue after an internal (fatal) error.
> > + Can a mercury program call abort() like one can in C?
> Yes. Mercury can't prevent anyone doing so anyway.
What I mean is, do we provide something like abort in Mercury? (I don't remember one myself), something like:
:- pred abort(int::in, io::di, io::uo) is det.
Which doesn't return.
By making the determinism of abort/3 det, you are telling the compiler that it _does_ return.
A better signature would be:
:- pred abort(int::in, io::di) is erroneous.
In any case, I don't see the need for abort in Mercury. Every time I have needed something like it, throwing an exception back to the top-level has always sufficed.
|Okay cool, I wasn't proposing abort/3 just asking if we already had something like this.|
|2014-06-20 10:30||wangp||New Issue|
|2014-06-20 11:49||pbone||Assigned To||=> pbone|
|2014-06-20 11:49||pbone||Status||new => assigned|
|2014-06-20 11:49||pbone||Note Added: 0000702|
|2014-06-24 12:37||juliensf||Note Added: 0000705|
|2014-06-26 18:50||pbone||Note Added: 0000712|
|2014-06-27 10:51||wangp||Note Added: 0000714|
|2014-06-27 10:55||pbone||Note Added: 0000715|
|2014-06-27 11:09||juliensf||Note Added: 0000716|
|2014-06-27 11:20||pbone||Note Added: 0000718|
|2015-11-02 11:41||pbone||Target Version||=> 15.11|