[m-rev.] for review: stand-alone interface and non-C grades

[Paul Bone]

On Thu, Dec 04, 2014 at 08:23:28PM +1100, Julien Fischer wrote:
>
>
> On Thu, 4 Dec 2014, Paul Bone wrote:
>
>> On Thu, Dec 04, 2014 at 04:29:59PM +1100, Julien Fischer wrote:
>>>
>>> For review by anyone.
>>>
>>>
>>> Stand-alone interfaces and non-C grades.
>>>
>>> Clarify the situation with stand-alone interfaces and non-C grades.  The
>>> documentation currently says that they are not currently supported for the
>>> non-C grades, which is inaccurate.  They are not actually required for the Java
>>> and C# backends.  The may however be needed for Erlang.
>>>
>>
>> I'll double check the situation regarding the new thread pool code in the
>> Java grade.
>
> The thread pool code shouldn't have anything to do with runtime
> intialisation though should it?T

The thread pool needs to be initialised.  it's true that this can happen
when it's first used however that's why I mentioned the specific issue
below.

>> I beleive that if your program uses threads, specifically anything
>> that uses semaphore.m it assumes that your Mercury code is being
>> executed by a Mercury thread.
>
> I'm don't follow you -- when would Mercury code not be executed by
> a Mercury thread?

When you call into it from your application using one of the application's
threads, including the initial thread (I think, this is what I need to
check).

Also now I think about it, how are module initialisers and finalisers called
on the Java backend when the Mercury code is used like this?


-- 
Paul Bone