grauzone wrote:
John Reimer wrote:
ddl does not work for memory sharing like normal dll's, where multiple
applications have access to a single dll at runtime. It appears that
such support would be quite difficult to implement and moves in the
direction of operating system features.
Couldn't this be achieved by simply mmap()-ing the file contents into
memory? mmap() normally shared the memory pages with other processes.
Of course, this wouldn't work if the code both isn't position
independent, and needs to be relocated to a different base address. But
that's also the case with operating system supported dynamic shared
objects.
It does do runtime linking, however, which is extremely useful for
certain situations... specifically any sort of application that needs
a plugin architecture for D (ie.. it can link with libraries and
object files at runtime) that is gc and exception friendly.
I never understood why this is needed. Can't they simply compile the
plugins into the main program?
Well, compiling them directly into the main program kinda defeats the
purpose of runtime-pluggable plugins, wouldn’t it?
When it's a commercial program, the DLL plugin approach probably
wouldn't work anyway: in order to enable others to compile plugins, you
would need to expose your internal "headers" (D modules). Note that
unlike in languages like C/C++, this would cause internal modules to be
exposed too, even if they are not strictly needed. What would you do to
avoid this? Maintain a separate set of import modules?
Make use of .di files. You don’t have to distribute code.
