[m-rev.] diff: Fix a deadlock in the Java worker thread implementation

[Julien Fischer]

Hi Paul,

On Tue, 12 Apr 2016, Paul Bone wrote:

> +                catch (InterruptedException e) {
> +                    /*
> +                    ** A worker thread has no semantics for this, so we continue
> +                    ** looping.
> +                    */
> +                    continue;
> +                }
> +                if (task != null) {
> +                    try {
> +                        setStatus(ThreadStatus.WORKING);
> +                        task.run();
> +                        pool.taskDone(task);
> +                    } catch (jmercury.runtime.Exception e) {
> +                        // The task threw a Mercury exception.
> +                        pool.taskFailed(task, e);
> +                        JavaInternal.reportUncaughtException(e);
> +                        // Make the thread exit after throwing an exception.
> +                        break;
> +                    } catch (Throwable e) {
> +                        // Some other error occured. bail out.
> +                        System.err.println("Uncaught exception: " + e.toString());
> +                        System.err.println(e.getMessage());
> +                        e.printStackTrace();
> +                        System.exit(1);

We need an alterative to calling System.exit in the Java version of the
runtime.  If Mercury code is deployed as a servlet, then calling
System.exit may cause the servlet container to halt as well.

The only place we should be calling System.exit is in the generated
main method for Mercury executables.

Julien.