Michael Van Canneyt wrote:
However I'd precede that by a thought based on what Jose said. In
your example, you're opening the database in the initialisation
block of businesslayer.pas, which is invoked at an arbitrary
position in the init sequence of the DLL/so. If that operation were
moved instead to the initialisation block of testdbdll.lpr, which in
the context of the DLL/so is analogous to a program's main block, it
might work.
No. this is not correct. For a library, this is analogous to
initialization code of a unit, it's just the 'last' unit being
initialized.
Does the main program explicitly call the initialisation entry point
of the (dynamically-loaded) library, or it this done by the OS? I was
under the impression that the two were basically asynchronous and (as
a particular example) both the program and the library would have
distinct copies of the system unit with their own global variables
etc. hence the memory manager problem.
The memory manager problem is completely unrelated to this. DLL and
calling program simply have different copies of the FPC memory manager.
That is what needs to be solved with dynamic packages.
Yes, agreed. Except that if cmem (or whatever) isn't being used there
are two completely separate copies of the memory manager because...
As far as I know, the initialization entry point is called automatically.
But the compiler experts should confirm this. IIRC the behaviour changed
as the support for libraries improved;
..(pending comment from compiler experts) there are completely separate
trees of units in the main program and each dynamically-loaded library.
The OS calls the initialisation block(s) for each library, and then
finally calls the initialisation block for the main program. So in the
context of one particular library, code in the main library
initialisation block should have a similar standing to that in the main
program initialisation block: everything else in that context (i.e. in
the library or in the main program) has been initialised before it is
called, and when it exits it goes back to the OS (possibly via
finalisation blocks).
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
