Re: static linking and dlopen

[Rich Felker <dalias@aerifal.cx>]

On Sat, Dec 08, 2012 at 03:17:09PM -0800, Charlie Kester wrote:
> I wonder if most of what people want to do with dlopen couldn't be
> done just as well (or better) with good old fork() and exec(), along
> with some suitable interprocess communication.

I think it depends a lot on what you're using dlopen for. A lot of
programs these days use it as a ridiculous part of the development
model rather than for any real purpose; in my book, this is among the
highest levels of Considered Harmful. There's really no reason for any
code that's internal to an application (developed in the same tree, by
the same authors, and built at the same time) to be dynamically linked
at all, much less dynamically loaded. All this accomplishes is making
the program a lot slower and more bloated.

On the flip side, the main legitimate uses for dynamic linking and
loading are (1) sharing code that's used by a wide range of
applications and allowing it to be upgraded system-wide all at once,
and (2) facilitating the extension of an application with third-party
code. Usage 1 applies mostly to dynamic linking; 2 mostly to dynamic
loading (dlopen).

As for your suggestion that dlopen could largely be replaced by
running an external program, that's definitely an alternate way to
accomplish extensions/plug-ins (see GIMP, for example). How well it
works probably depends on the performance requirements (it's hard to
get good performance if the plugin is dealing with high volumes of
data unless you develop complex IPC methods using shared memory, so
there's a complexity trade-off too) and whether your extensions need
to survive across fork (which does not duplicate a process's child
process trees; this could very well matter for extension modules used
by language interpreters/runtimes like Python, Perl, etc.).

Rich