[Kamailio-Devel] question regarding fork and kamailio global variables usage

[Henning Westerholt]

On Friday 02 January 2009, Kalpesh Rathod wrote:
> I am porting kamailio to the OS which doesnt support fork. For the OS,
> tasks are similar to threads of same process in Linux.

Hi Kalpesh,

sounds interesting, what kind of OS is this?

> In this environment, child task(s) will share the global and heap data with
> parent instead of having separate copy of the data.
> Its analogus to using mutiple threads instead of multiple processes in
> kamailio.

Understand. Not sure if this also applies to this situation, but i experienced 
some problems in the past using threads with kamailio.

> My question is , kamailio supports USE_SHM_MEM which allows all the
> pkg_mallocs to become shm_malloc. This way
> I dont need to be concerned about access of data in heap while porting
> because code is designed that way.
> Is my understanding true?

If you define USE_SHM_MEM, and not PKG_MALLOC, then all pkg_* calls will be 
mapped to the respective shm_* calls. I haven't used this mode yet, so i 
can't comment if this works reliable. But if you found any bugs in this mode, 
please report them to the list.

> How are the global variables accessed? especially, though data is in
> shared mem, the variable holding address of data is defined as
> global variable.

To what kind of global variables do you refer to? In the shared memory the 
access to the data is guarded by the internal memory manager. You find it in 
the mem/shm_mem.{c,h} files.

> So,after fork parent and child both interprete global data differently or
> is there any design rule enforced that after fork no.process
> will be writing global data. (igonre the cleanup for a while). Will there
> be any any problem if I dont give child task its own copy of
> global variables and let them use the same copy as parent?

Each module uses its global data (shared memory) differently. For example the 
carrierroute module initialize it before the fork in the mod_init(), but its 
also updated from the FIFO process later on. With regards to the private 
data, as long as each task can use their own memory, it should work ok. If 
different task share the same memory location (for their "private" data), the 
locking mechanism that are in place in the SHM_MEM MM should prevent problems 
caused from concurrent access.

Does this answer your questions so far?

Henning