On Thu, Jan 27, 2005 at 05:19:52PM -0500, Greg A. Woods wrote:
> And if you want a truly dynamic execution environment then why the heck
> aren't you using an interpreted language (or at least JIT
> byte-code-compiled one)?!?!?!?

You are arguing about speed and suggest an interpreted language?
Heck, I could do this by embedding an C compiler, but that's not the
point.

> This perceived need for dynamic loading of machine code (as opposed to,
> and separate from, shared libraries) is bogus in 99.99% of situations,
> especially now that modern processors are fast enough to make even
> languages like Smalltalk run at speeds well beyond those required for
> implementing full real-time graphical user interace environments.

I consider including all the possible converion code bogus too.
I don't want to stop you from compiling in static modules, if you
want too. But you have to face the problems arising from having to
decide e.g. which character sets to support in an application
before.

> Perhaps, but in addition to the problems Jason also mentioned, the mere
> alloance of dlopen() from a static-linked program would completely
> violate the security model those of us who want static linking depend
> upon.

This argument is just ridiculus. Nothing prevents an application from
using dlopen-like mmaps at all. If you want to prevent it from dlopen
e.g. a citrus module, override the dlopen used for static-linked
programs. Make is a compile-time switch, use linker sets to compile
the modules of interest into the program, but stop the need for hacks
in libc.

> > Also keep in mind that for the intended use, the overhead of PIC is
> > very small or not existing, because the code itself is often called
> > via function pointers anyway.
> 
> Maybe it is small on your choice of processors, but that is not true for
> all, at least not according to the benchmarks I've run.
> 
> Keep in mind that all dynamic-loaded code _MUST_ be PIC on some CPUs.

If you don't want to do text relocations, yes. If you want to call
outside the library, yes. For local symbols, a lot of processors allow
efficient access mechanisms even for PIC. Some CPUs are PIC anyway.
It's a trade-off. But I consider the single-tree approach and having
identical code for citrus more interesting than the low-level merits of
dlopen.

> Besides, for the likes of citrus the very idea of implementing it in
> such a way that it requires dynamic loading of machine code is an
> extremely poor design choice -- maybe it's easy to implement that way,
> but it's wrong.

I disagree here. The situation becomes even more clean if you consider
the natural extension of the current citrus framework to cover the
featureset of ICU, which means a lot more language-sensitive information.

Joerg