[m-rev.] for review: add example of calling Mercury libraries from Java

[Paul Bone]

On Fri, Dec 05, 2014 at 11:14:20PM +1100, Julien Fischer wrote:
> On Fri, 5 Dec 2014, Paul Bone wrote:
>> On Fri, Dec 05, 2014 at 08:07:54PM +1100, Julien Fischer wrote:
>> In a workspace on my machine I've fixed the issue with creating the thread
>> pool.  However there are some assumptions inside MercuryThreadPool that I
>> made and will take longer to fix.  It looks as if the simplest fix will be
>> to require users to call something to close the thread pool when they're
>> finished with it.  So I can make the new MercuryRuntime class have a method
>> called finalise() that does both run_finalisers() and stops the thread pool
>> (if it's been started).
>
> Having just a single method called finalise that is responsible for all
> Mercury finalisation would be analagous with what the C backend does.

Okay, cool.

>> Rhe more complicated solution is to make the thread pool threads
>> "daemon" threads, which is Java-speak meaning that the threads will
>> exit of the main thread exits.  The problem with that is that it may
>> differ from other Mercury backends.  I beleive that we want all
>> backends to wait for thread.spawn tasks to finish before finishing
>> themselves, and depending on the application some of these tasks may
>> need to write and close files.
>
> Above all what we want is for all the backends to behave consistently.
> Do we actually document the current behaviour anywhere?

I don't think it's documented.  But when we discussed this in the past we
agreed that the runtime should wait for all threads to finish before it
stops the program.

https://www.mercurylang.org/bugs/view.php?id=336

>> I'm leaning towards the first solution, especially since there would be a
>> run_finalisers() function anyway.  Does anyone see any problems with that?
>
> We'll add the finalise method to the new MercuryRuntime class and you
> can hook it into that.  You should probably shut down the thread pool
> *after* the user-specified finalisation predicates have been called
> anyway.

Agreed.


-- 
Paul Bone