Full-Speed Simulator
		        16 Dec 2015

			Meeting Notes



*** Overall Objectives:  ***

  1) Fix the Resource Unavailable bug.
  2) Test on the vehicle. Check into the branch.
  3) Merge with the trunk.
  4) Start a new branch and proceed with combining Navigation, DynamicControl
     and Layered Control into one process.

Hans, Rob, Rich and Kent were there.  The following are notes from Kent and
Rich, mostly on what Hans was saying.



***  Notes:  ***

Resource unavail
Two types of sems named, unamed
Limit on named sems
Can look in dev/shmem for named sems

Can increase number of sems
But why are we hitting limit
Why doesn't simulator hit same limit

Sim instruments don't have as many sems.

May be limit total shmem memory limit
Allocated a page at a time, shmem allocates to nearest page 

Error messages seem to be at semaphore construction

Not  sure if it's always the same process that runs out.
Need to reproduce on live system, then look for stale processes, left over shmem, etc.

Resource unavail has occurred w stock build, always associated w stale dev shmem

Fast time init by supervisor must be explicit either way.
What to do if not using supervisor...eg stand alone test?
Could use environment flag , supervisor does setenv, then use shmem to pass time for sims.

Ctrl c when layered control destructs, event trigger table stuff has two parts.
Dynamic array template class destructor seems to be causing problem.
system hangs when delete event trigger object.

There are proxies, these are freed on free call.
Thought proxies have copied
Hans detached the proxy before destruction and it didn't change anything.

What if you skip event trigger destructor? All exits normally

There is some kind of handshake between layered ctrl and its server.

Rich will work on conditional compile
Kh will work on env var update
Hans will chase ctrl c
Rob  will run some missions to reproduce on vehicle

Semaphores:

	Can we just syslog the semaphores that each process has?
        There are two types of semaphores.
        Does each process call FastTime::sem_init() only once?
        Are we hitting a limit in the shared memory page allocation? System
        allocation is a page at a time.
        Errors seem to occur when creating semaphores.
        128 pages allocated?
        Always the same process complains?
        System unlinks the memory segment, system releases when reference count == 0
        Hans has seen this problem before FastTime integration.
        sem_wait() is called only once on the target.
        Need to fix FastTime initialization to set fast time on to false.
        Use environment variable to signal a FastSim.