I need a design which requires complete modularity and speed. I have a huge monolithic process that i'm seperating now with individual modules as libraries.

I'm just worried how to go about the no of shared libraries? for example can i have 10 shared libraries in place of 1? what will be the advantage in that case?

Dividing a program into libraries has the advantage of reducing the complexity of maintenance -- if you need to change a single or a few functions, you can do so in a library quickly and easily without needing to recompile an entire program (or any other libraries). Dividing functions into multiple libraries of related functions is a reasonable approach. The advantage here is maintenance and generally is useful if a lot of changes and updates are expected. This is, I believe, true of both static (libname.a) and shared libraries (libname.so).

It's probably always better to write from the perspective of main program plus one or more libraries. Other than the maintenance advantage, libraries are most useful when more than one program or more than one instance of a particular program is going to be executing at the same time (as in multiple users executing the same program simultaneously or multiple users executing different programs that use some of the same functions); that's where libraries, particularly shared libraries, shine. This is because shared libraries are loaded by programs when they start and any additional programs that start later will use the shared library without reloading it -- it's a little more complicated, but that's essentially what happens.

So, can you have more than one shared library? Sure. Can you have many? Sure. How many is a balancing act that takes into account maintenance (how often do you make changes or add functions), how much active work do you do on your application. On a modern system there really isn't that much overhead involved in loading multiple libraries; if the thing is stumbling over its own feet now just dividing it up into libraries isn't going to make a heckuva lot of difference. Just try to separate your functions into groups that make sense to you and you'll probably be all right.

Hope this helps some.

1 members found this post helpful.

Why does it require modularity and/or what do you mean by "modularity".

Any big software project ought to be modular in its structure of source files. Modularity in the build sequence and dependencies is also likely a good idea. But none of that requires shared libraries.

Shared libraries might support modularity in the distribution process, but that generally doesn't work very well nor save enough to be worth the trouble.

The modularity of shared libraries is much more important when multiple executables need the same functions.

So what purpose / kind of modularity do you actually require?

There is some tradeoff vs. speed. Code in a .so can be noticeably slower than the same code in the main executable. Usually that is not a significant factor, but since you mentioned speed, you should be aware that there might be an issue.

The run time disadvantages of ten .so's in place of one are generally smaller than the already small disadvantages of .so's in place of linking directly into the main executable. I don't think you want to worry about those disadvantages.

But why ask us what the advantages are? That totally depends on what you are doing. There is no generic advantage to .so at all and certainly no generic advantage to more .so files vs. fewer. The specific advantages depend on your situation:

Are you distributing updates through some limited or low speed channel and also updating different parts of the project on different schedules?

Are you creating several different executables that each need a different subset of a library of shared functions?

Those are the kind of issues that might push someone toward using a larger number of smaller .so files.

I think the advantage for shared libraries for more than one instance of a program is an obsolete concept. The main program image should be just as shareable between multiple instances as the shared libraries. The loader maps most of the main image into the virtual address space rather than reading it into anonymous memory. Like any other mapping of a file into memory, resident pages will be shared by any other process that maps the same file and has the same pages resident.

Shared libraries are most useful when more than one program (not instances of one program) uses the same functions.

1 members found this post helpful.