On 9/12/21 1:25 PM, NonNull wrote:
On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote:
All initialization functions of the plugins were called automatically
in my D test environment and all plugins were usable. The trouble
started when the main library was being used in a foreign
On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote:
All initialization functions of the plugins were called
automatically in my D test environment and all plugins were
usable. The trouble started when the main library was being
used in a foreign environment (something like Python
On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote:
All initialization functions of the plugins were called
automatically in my D test environment and all plugins were
usable. The trouble started when the main library was being
used in a foreign environment (something like Python
On 9/12/21 7:31 AM, NonNull wrote:
> I am making a plug-in development system for a high performance Linux
> application that already exists and is written in C and will not be
> modified for this purpose.
I've done something similar but in my case the main application is in D
and the plugins
On Sunday, 12 September 2021 at 16:23:13 UTC, frame wrote:
Shouldn't the runtime not already be shared on Linux? The
`Runtime.loadLibrary` specs say
`If the library contains a D runtime it will be integrated with
the current runtime.`
This should be true for the GC too. At least the memory is
On Sunday, 12 September 2021 at 14:31:04 UTC, NonNull wrote:
If several plugins are built by different third parties, each
dynamic library will have its own GC and copy of druntime right
now. How can I organize that there is one separate dynamic
library to share these among all plugins?
