Signal simulation through Python scripts using shared memory for testing a C application This is bit long, but I need to explain something before I can ask for actual reviews/advice.

I have to test generated C code from Matlab Simulink model. I can create a executable binary from those.  I need to test this application using tests developed using Python scripting.

I came up with following approach: inter-process communication using shared memory.

I planned to write a DLL or a shared object, which enables the communication between the tests scripts and the application.  This DLL will be used via both Python scripts and application to interact with each other

Here's my DLL code, which uses boost::interprocess shared memory.

int create_shmem(const char* shmem_name, long long length  )
{
    try{
       // remove_shmem(shmem_name);
        boost::interprocess::shared_memory_object shm 
                          (boost::interprocess::create_only,
                           shmem_name,
                           boost::interprocess::read_write);
      //Set size
      shm.truncate(length);
      return 1;
      }
      catch(...){
        std::cerr &lt;&lt; "Error Creating Shared Memory : " &lt;&lt; shmem_name &lt;&lt; std::endl;
      }
      return 0;
}

int remove_shmem(const char* shmem_name )
{
    try {
        boost::interprocess::shared_memory_object::remove(shmem_name); 
        return 1;
    }
    catch(...){
        std::cerr &lt;&lt; "Error Removing Shared Memory : "&lt;&lt; shmem_name &lt;&lt; std::endl;
    }
    return 0;
}

int write_shmem(const char* shmem_name, char* shmem)
{
      try{
            boost::interprocess::shared_memory_object shm
            (boost::interprocess::open_only, //Open if already created
                 shmem_name, 
             boost::interprocess::read_write);

      //Map the whole shared memory in this process
            boost::interprocess::mapped_region region
                (shm, 
                boost::interprocess::read_write
                );

            std::memcpy(region.get_address(), shmem, region.get_size());
            return 1;
      }
      catch(...){
         std::cerr &lt;&lt; "Error Writing to Shared Memory " &lt;&lt; shmem_name &lt;&lt; std::endl;
      }
      return 0;
}


int read_shmem( const char* shmem_name, char *shmem )
{
      //Open already created shared memory object.
     // Same process might not be calling it, so create new object
     try{
            boost::interprocess::shared_memory_object shm (
                boost::interprocess::open_only, 
                    shmem_name, 
                    boost::interprocess::read_only);

      //Map the whole shared memory in this process
            boost::interprocess::mapped_region region
                (shm, 
                     boost::interprocess::read_only
                );

      //CAUTION : No check is performed
    std::memcpy(shmem, reinterpret_cast&lt;char*&gt; (region.get_address()),
                       region.get_size()); 

      return 1;
      }

      catch(...){
      std::cerr &lt;&lt; "Error Reading from Shared Memory " &lt;&lt; shmem_name &lt;&lt; std::endl;
      }

   return 0;
}


The application needs simulation of around 1.5K different signals of different data types all packed in a C struct. 

My initial though is to created a shared memory and write the simulated signals on to it which the application can fetch and accordingly shows the output by writing back to same shared memory which is again read from test scripts.

Any help/advice regarding underlying issues/failure and improvement will be much appreciated.

I can post my ctypes Python interface if required.
It is short and to the point. Looks fine.


  used via both Python scripts and application to interact with each other


You didn't describe the interaction, in English nor in code. Maybe the two sides routinely manipulate lots of data structures (1500 signals didn't quite sound like "a lot") that the other side uses less than 1% of the time, so your code or the multiprocessing support that ppperry highlighted would be appropriate. But the interaction is going to require condition variables or mutexes or higher level coordination such as queues. Since you've not specified the performance characteristics, I would just start with a TCP connection, or pub-sub, and go from there, see how things shake out. Localhost TCP offers very high bandwidth, and low latency. Profiling might reveal a need for shmem, but I'm skeptical, and it's better to cross that bridge after it's clear that you need to.