Conference azur::mcc

Bonnie - it two threads can access the data in a read/write fashion, you
will have to use mutexes to protect the data.

How often are you going to translate the environmental/logical variables?
Only when the MM is loaded into memory?  Each time a directive is performed?

If you only need to translate once, then the 'mcc_once' routine will take
care of it - and has a mutex built-in too

See the t1.2.4 toolkit release notes for more information on MCC Mutexes and
the mcc_once routine.

/keith

   > How often are you going to translate the environmental/logical
   > variables? Only when the MM is loaded into memory?  Each time a directive
     is performed?
    
    Well, there are environment variables which each user can set at a
    terminal, before invoking mcc.  This is assuming the mcc has already
    been enrolled, and that several different users can access it with
    different environment variables.
    
    So, its really once per "session", if that makes sense. I only need to
    translate once, but at the beginning of a user getting the MCC prompt. 
    I'm not quite how often the MM is loaded.   
    
		thanks,
    
    			Bonnie
    

>    So, its really once per "session", if that makes sense. I only need to
>    translate once, but at the beginning of a user getting the MCC prompt. 
>    I'm not quite how often the MM is loaded.   

You are going to have to be really careful here.
The DECmcc/ULTRIX execution model is that each MM runs in its own process
(one per user).  These processes do not terminate until explicitely
stopped with mcc_kill.  So if a user enters DECmcc (eg issues "manage"),
and then issues some directives, relevant MMs are started in their own
processes.  If the user then exits from DECmcc, sets the environmental
variables, and reissues the "manage" command, only the FCL will
have access to the new environmental variables.  The existing MMs
will still be running in their own processes, and will not have access
to the new environmental variables (regardless of when you try
to translate them).

-- Erik

    Also, all users with a given UID share a single copy of each FM and AM
    in use.
    
    In general, environmental variables are not a good mechanism to use in
    a multiprocess application (MCC or any other) because they are copied
    on process creation and eventually you have potentially "n" different 
    values of the same variable.
    
    Other U**x multiprocess applications (Ingres is a good example) that
    need an env var type facility usually do it by maintaining the
    variables in a file which all processes read.
    

    >In general, environmental variables are not a good mechanism to use in
    >a multiprocess application (MCC or any other) because they are copied
    >on process creation and eventually you have potentially "n" different
    >values of the same variable.
    
    I don't understand why this is a problem, if you want your system to
    work that way. If you had 2 interdependent pieces of a system each with 
    a different environment variable, this could cause problems, if the 2 
    processes were meant to operate in the same environment.  
    
    >Also, all users with a given UID share a single copy of each FM and AM
    >in use.
    
    This does seem like a problem. The environment variables are the 
    database, the CDS directory.  We need to be able to have the users
    change this, we want different sessions to be able to have different
    environment variables.
    
    The AM could translate them on every call, but it seems like so much
    overhead.  There are at least 5.
    
    		Bonnie 

>    The AM could translate them on every call, but it seems like so much
>    overhead.  There are at least 5.

This still doesn't help.

Environmental variables are process based.  Once an MM is started
(in its own process), you can never change the value of the environmental
variables in that process, other than by a system call from the MM itself.
You can translate it as many times as you want, but the value will
always come back the same.

Currently, MM processes run indefinitely.  So the first time a user
dispatches to your MM, that MM starts in a process that has the same
environmental variables as the process running the PM that started it.
Any other "session" running under the same UID will dispatch (over RPC)
to that same MM process, and will be unable to change the environmental
variables in it in any way.

That is why Jim has suggested a mechanism other than environmental
variables for what you are trying to do.

-- Erik

    
    I see what you mean about environment variables. Is there some more
    about how a management module executes in a threading environment?
    That is, without specifically creating threads with the mcc routines.
    (Is each directive a thread?)  I have to allocate/deallocate memory
    on each directive, but I was considering keeping around the memory
    and re-using it. (FRom ILV the data goes into c buffers, the attributes
    with a fixed size could be kept around and reused.) Is it possible to use 
    pthread_ routines, or does it even make sense in this environment.
    
    		thanks,
                               
    			Bonnie
    

    each time we go across the call interface you will get a new stack to
    run in, so unless you do something to keep those global variables
    around reusing them won't do much good. Please note that the kernel
    people are working on schemes to help out with the memory management in
    the system. But memory usage by MCC is still way to high; don't keep
    anymore memory allocated to your process than absolutely necessary and
    always test your code for memory leaks.