On Wednesday, 9 January 2013 at 09:35:28 UTC, deadalnix wrote:
On Wednesday, 9 January 2013 at 08:46:20 UTC, Paulo Pinto wrote:
You can write plugins without dynamic loading, they just are a
bit more cumbersome to write.
Like I used to do back in the late 90's, by making use of
UNIX's IPC.
The IPC to use (shared memory, pipes, mailbox, sockets)
depends on what is required from the plugin. With shared
memory being the closest to what dynamic loading achieves.
Of course this raises another set of issues like:
- Take care what happens when a plugin dies
- Too many loaded plugins can stress the scheduler
- You might have synchronization issues when using shared
memory
- It is a bit more painful to code for
This is the school of thought of the Plan9/Go guys and most
operating system micro-kernel architectures.
Such a solution cause the same kind of issue for the runtime.
For instance, how to handle the garbage collection of the
shared memory ? What do happen if I get the typeid of an object
of a type that only exists in the plugin in the core app ?
It quite don't solve problems we have.
Usually you serialize the data into the shared memory when using
stronger type languages and only use public types defined in the
common interface between the main application and plugins.
--
Paulo
