"grauzone" <[email protected]> wrote in message news:[email protected]... > Alexander Pánek wrote: >> 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? > > But why do you want them in the first place? For Open Source projects, > this seems to be completely pointless to me. >
With runtime-pluggables: 1. A program can download, install and use a plugin without the program needing to be restarted. 2. Out of all existing plugins, any arbitrary subset can be enabled without requiring an exponential number of pre-compiled executables, without requiring the user (or the program itself) to recompile anything, and without needing to install any build tools on the user's system.
