[m-dev.] Initialising the Mercury runtime in .NET

[Fergus Henderson]

On 13-Oct-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> Before one can use Mercury.NET, one must call io__init_state.
>
> Currently this is done by inserting the call to MR_init_runtime, which
> simply calls io__init_state but may at a later date do more, in the
> class constructor (.cctor) of the assembly containing main/2.  This is
> problematic if you want to use a Mercury.NET assembly as a library as
> then this routine isn't called.

It is problematic if you don't call it, yes.

There is a fairly straight-forward solution, however: call it.

> The simple solution would be to hard code the call to io__init_state
> from the .cctor of io instead of from MR_init_runtime.

When you say hard-coding the call, do you mean having the
compiler automatically insert that call when it is generating
the .cctor for io, like the way it currently inserts the call to
private_builtin.init_runtime/0 in main/2?

You'd need to be careful about the order of initialization.
In particular, io__init_state/2 requires that the type_ctor_infos
for other modules, e.g. string and int, be initialized first.

Initialization of the Mercury library requires several phases.

	1. Allocate all the type_ctor_info structures,
	   but do not fill them in yet.

	   In this phase, each module's initialization code
	   must not yet refer to variables in any other module.

	2. Fill in all the type_ctor_info structures

	   This phase may refer to the addresses of type_ctor_info
	   structures in other modules, but not to their contents.

	3. io__init_state/2

	   This phase may need to refer to the contents of
	   type_ctor_info structures in other modules,
	   e.g. to determine the address of the comparison
	   function for "int" in order to insert the stream_ids
	   into the stream_info database.

Currently phases 1 and 2 are done in the .cctors, and phase 3 is done
in main/2.

Changing this so that phase 3 is done in the .cctors is not trivial,
I think.  Suppose a user module m1 calls a library module, say term_io.m,
which requires io__init_state to have been called.  Then with the
current scheme for initialization, modified with your suggestion above,
we'd get the following sequence:

	m1::entrypoint
	  term_io::.cctor
	    phase 1 for term_io
	    io::.cctor
	      phase 1 for io
	      term_io::.cctor
		skipped since already in progress
	      phase 2 for io
	      phase 3 for io
	    phase 2 for term_io

As you can see, phase 3 for io occurs before phase 2 for term_io,
which is a no-no.

So if you want to do all three phases in the .cctors, then I think the
code for the first two phases would have to be split out into separate
functions, rather than being inline in the .cctors as it is currently.

> However I believe we should be able to offer a better solution to this
> problem, as it has come up before in the need to run a predicate once to
> initialise a solver engine for HAL and I have encountered a similar
> problem where one needs to run some setup routines before running any of
> the MS sockets stuff.
> 
> Does anyone have any suggestions?

Any automatic and fully general solution would need to be quite
complicated in order to deal with complex initialization dependencies
such as the three phase initialization mentioned above.  I suspect that
such solutions are unlikely to be of sufficient benefit to be worth the
costs at this time.

So for now I suggest that you document this issue in the Mercury user's
guide and/or the language reference manual, and for cases where Mercury
on .NET is used for implementing a library, leave it up to library users
to explicitly invoke the initialization.

P.S. Pete, please fix the regressions that your earlier changes in April
introduced before starting development of any new features!

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------