[sr-dev] git:master: mi_rpc: new module - rpc command to execute MI commands

[Andrei Pelinescu-Onciul]

On Jul 01, 2009 at 09:11, Juha Heinanen <jh at tutpro.com> wrote:
> Daniel-Constantin Mierla writes:
> 
>  > seems some MI commands needs a bit of review and fix to work over rpc, 
>  > because in some cases they do not open db connection in all children, 
>  > like it was with domain module. It opened only in the mi transport 
>  > process. It should be fixed now. Let me know if works ok.
> 
> i works, but i'm wondering why the condition in child_init of
> modules_k/domain module is:
> 
> rank==PROC_RPC
> 
> but in modules/lcr it is:
> 
> #ifdef RPC_SUPPORT
> 	/* do nothing for the main process, tcp main process or timer */
> 	if (rank==PROC_INIT || rank==PROC_MAIN || rank==PROC_TCP_MAIN ||
> 		rank==PROC_TIMER)
> 		return 0;

It's the reverse, the condition in the domain module is for what
processes to init the db, while in lcr is for what processes not to init
the db (notice the return 0 if the condition is true).

In the domain module child_init the condition for initializing the db
is:
if ( (db_mode==0 && rank>0) || (rank==PROC_RPC) )

which is equivalent (for db_mode==0) with:
   rank!=PROC_MAIN && rank!=PROC_TIMER && rank!=PROC_TCP_MAIN &&
   rank!=PROC_UNIXSOCK && rank!=PROC_ATTENDANT && rank!=PROC_INIT

 (all the above ranks are <=0, all ranks < 0 are "special").

So compared to lcr it handles 2 more ranks PROC_UNIXSOCK &
PROC_ATTENDANT , but PROC_UNIXSOCK is obsolete (it was another way to
communicate with tm which is no longer used) and PROC_ATTENDANT is used
for other stuff (is not used for child_init) => they are equivalent.


Andrei