[m-dev.] special module initialisation code

[Fergus Henderson]

On 21-Mar-2000, David Overton <dmo at ender.cs.mu.oz.au> wrote:
> I am currently in the process of writing a new module to integrate
> Peter Schachte's C implementation of ROBDDs with Mercury.  The
> interface to Peter's code is declarative, except that an
> initialisation procedure needs to be called to set up some tables
> before any of the other procedures in the module can be used.
> 
> It would be nice if there were some way of automatically getting this
> procedure called at program startup if the ROBDD module has been
> imported.

One way to do this is to convert the C implementation of ROBDDs to C++
(using `extern "C"' so that it can be accessed using Mercury's C
interface), and to have it contain a global (or file-scope static)
variable whose constructor performs the necessary initialization.

> I believe a C function `mercury__<module>__init()' is generated for
> each module and called when the program starts up.

That is not quite correct.  These functions are only called
at startup in certain grades.  In other grades, they may
be called later, or they may not be called at all.

The reason for this is that calling a function in every module
forces most of the executable to be paged into memory,
which significantly slows down program startup.

> One possibility is to add a new pragma, `c_init_code', which is
> similar to `pragma c_header_code', except that it puts the code inside
> the `mercury__<module>__init()' function instead of at the top of the
> .c file.

Well, that won't work, for the reasons explained above.

It would however be quite possible to implement a pragma `c_init_code'
with the semantics that it was run before main/2, and without
adversely impacting efficiency if it wasn't used; it would just
not be quite as easy to implement as the approach you suggest.
You'd need to add extra support in util/mkinit.c.
Also it might increase build times a bit.

However, if you are going to add such an automatic initialization
feature, then you need to consider the order-of-initialization
problem.  What happens if the initialization code for one module
depends on the initialization code for some other module already
having been run?  This is a fairly common situation, so if you
are going to add such a feature, then IMHO it really ought to
address that issue.  This of course will further complicate the
implementation...

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- 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
--------------------------------------------------------------------------