Samba as library

[John E. Malmberg]

Peter Samuelson <peter at cadcamlab.org> wrote:

> [Claudia Moroder]
> > But having many smbd means using much memory.
>
> No.  The text segment of the executable (i.e. the program code itself)
> is shared between processes, just like shared library text.  The only
> time shared libraries save memory is if *different* executable files
> use them -- they are no advantage if you just have a *single* exe.

Since there seems to be some OpenVMS users lurking on this list...

In the OpenVMS operating system, each SMBD is launched as a separate
process, so installing the entire program as a shared image will save both
physical and virtual memory, thus improving the performance generally.

In the general case an OpenVMS program image does not have to be compiled or
linked special to do this.

A privileged image (SETUID) has to have a pointer to the symbol table NULLed
out so that it can not be invoked by a non-privileged image.

> > I' don't know how big the overhead is when i call .so libraries in
> > Linux and other unices ( I remember on the amiga there was a small
> > overhead ).
>
> Not sure how much overhead, but there is some.

In OpenVMS, an installed image is treated like a read only page file, and
kept open by the operating system.  You pay a few bytes for this in memory.
But consider, that the second concurrent invocation of an image that is not
installed will use far more resources than installing that image (and a
whole lot of other images), the tradeoffs become immediately biased in favor
of installing all programs that could have more than one concurrent
invocation.

Because the image is already opened, activation is faster.

Some system manglers are so concerned with saving physical memory for the
installed image, they avoid installing anything they do not have to.  It can
be easily shown that this is a more costly tactic.

> Finally, runtime efficiency is also affected by the
> fact that shared libraries are compiled in PIC, or position-independent
> code, which on most architectures gives something of a performance
> penalty.

Again on OpenVMS, not an issue.  It takes a bit of work to keep the
compilers from building PIC.

A shared library must be linked specially to have a jump table at it's base.
This reduces the overhead in resolving the "fixup" vectors.  All access to
the library is through the jump table.

Bascially the only additional overhead at runtime is an additional long jump
at the start of each routine.  If that is an issue, overall, then that code
was better in-lined as a macro instead of a shared library.

Converting the SAMBA 2.0.6 I am porting to OpenVMS build to produce shared
libraries, was a considerable savings in disk space, and in build times.

And when the shared images are installed, I will get faster program startup
times.

-John
wb8tyw at qsl.net