Hi All,

I am building a queue system (in C on CentOS 5) where each directory queue has a number of process instances 'watching' it.

I have a root-permission queue supervisor process which does all the forking, and the instance processes give up root as their first action. For max security each queue is accessible to a different set of users and groups.

I need to keep the RAM requirements as low as possible, so I am relying heavily on copy-on-write (since all memory writes are to shmget() shared memory)

Each process presently dlopen's the libraries it requires after fork, but I'm wondering if I would gain by performing the dlopen before forking a number of instances which all require the same libraries.

Any pointers to mid-level tutorials on dlopen and fork internals would be most appreciated: this is about my third post anywhere since I converted to Linux, but I just can't find the answer to this anywhere online...

Regards,

Andy T

Sorry for this first stupid answer :-), but the man pages of fork(2) and dlopen(3) are quite useful as they greatly describe which attributes/"objects" get inherited.

What are you doing after the fork(2)? Any of the exec*(2) system calls?

After doing a fork(2), you get an exact copy of the parent process (see fork(2) for exceptions), though the libraries opened via dlopen(3) should be then available in the child process unless you do load a new executable.

Andi


Regards,

Andy T

Thanks for the answer :-)

No exec*'s just lots of forks running the same code as different users (hence pthread is out). Have checked those man pages, but they just don't quite ease my concerns about the interplay between fork, dlopen, copy-on-write and different real/effective users.

I guess my concern was how global each dlopen'ed dynamic library instance is:

1) If some other process has already dlopen'ed a library I plan to use, will my first dlopen call simply crank the reference count, or does my process get it's own private reference count initialised to 1?

2) Further, if my process gets it's own reference count=1 and it forks two children which also dlopen the same lib, do they get their own reference count set to 1?

3) Lastly, if the children switch to a different uid/gid before calling dlopen, does that affect the answer to 2)

Checking the clone man page, specifically CLONE_VM (not set), it looks like fork will copy(-on-write) mmap'ings wich could indicate that dlopen's are at least global to all the children I create.

Sadly, the design would have to change dramatically depending upon the answers to 2 and 3, so I need to be sure.

I think that sums it up,

Regards,

Andy T

The answer to this one is so simple, I'm embarrassed to post it:

All .so libraries are mapped to memory just the once, and a record added to the global kernel data structures.

Each process using the library simply gets an extra memory area descriptor pointing to the same mapping.

This makes the library 'appear' in the process address space, without having any noticeable impact on physical free RAM.

As each process starts or dlopen's to get this descriptor, the kernel increases the mapping's reference count.

As each process dies or dlcloses, the reference count is reduced and the mapping itself deleted if no remaining processes use the library.

As a result dlopen is probably best used when a single process must use a number of libraries heavily and sequentially.

If a process will require all cited libraries nearly simultaneously, the symbol resolution overhead of dlopen/sym means you may want to consider linking them in at compile time.

Hope this helps someone,

Regards,

Andy T