On Wednesday, 9 January 2013 at 02:49:34 UTC, Rob T wrote:
On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger
wrote:
On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
The only major thing that concerns me is the lack of proper
shared library support. I hope this omission is resolved soon.
What do you need it for? Runtime loading of D shared objects?
Or just linking to them (i.e. binding by ld/dyld at load
time)? I'm trying to collect data on real-world use cases
resp. expectations right now.
David
I *really* need runtime loading of plug-in code for a server
application. This allows the server code to remain untouched
while allowing extensions to be added on by a 3rd party.
Runtime linked shared libs are also nice to have for the simple
reason that shared libraries can be updated (to a point)
without having to rebuild and relink all applications that make
use of the libraries. There are pros and cons to static vs
dynamic linking, but definitely both are useful to have.
I'm very surprised that not too many people have been screaming
for dynamic linking and runtime loading. It's very hard for me
to imagine not having the feature because it's so darn useful
and an essential feature if your strategy is to allow 3rd
parties to extend an application without hacking at the source
code.
If there's another better way, I'd sure like to know about it!
--rt
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.
--
Paulo
