UserStackData

User stack data

The C signature for a MATLAB entry-point function is typically

void thread1(void)

but if reentrant code is requested (cfg.MultiInstanceCode = true) and the MATLAB code:

• contains very large variables
• calls certain MATLAB functions with state

then the code generator may produce code with a call signature like

void thread1(userStackData *SD)

or

void thread1(userStackData *SD, struct0_T *arg)

where SD is a pointer to statically allocated storage of type userStackData which is defined in user_data.h

#ifndef typedef_userPersistentData
#define typedef_userPersistentData

typedef struct {
  unsigned int state[625];
} userPersistentData;

#endif                                 /*typedef_userPersistentData*/

#ifndef typedef_userStackData
#define typedef_userStackData

typedef struct {
  userPersistentData *pd;
} userStackData;

The details of the structure/type will depend on details of the code. That storage must be initialized by an autogenerated function user_initialize.c which is called before the user function is invoked. The pd element must point to an instance of a userPersistentData type, either statically or dynamically allocated.

If the thread entry-point function requires a userStackData argument then this must be flagged to the thread stl.launch method by providing a third argument

stl.launch('thread1', arg, true);

At the C-level this causes the stack data pointer to be passed to the thread entry-point function as the first passed parameter. The argument, if present, is the second passed parameter.

Important notes

If the third argument to stl.launch is inconsistent with the generated code's use of a stack pointer argument then a run-time error will occur, most likely a segmentation violation.

If the user's main function user.m requires a stack pointer, this must be handled by editing main.c.

This part of the process is difficult to fully automate. It requires inspection of the generated C code