(This limitation does not apply to Linux or NT.)Specifically, threads initiated by TRIGGER_THREAD have a default stack-size-limit of 16-KBytes. This is large enough so that you do not normally need to worry about it. It is not an ultimate limitation because there are several easy alternatives. But it is good to know about it so that you avoid a potential pitfall if you are developing models which could stress the arbitrary default limit.
Local variables under a thread, declared
... are allocated from the thread's stack. Note that parameters passed
into any functions or subroutines, that are called from under a thread
as well as their local variables, are allocated from the thread's stack.
If a thread's stack were to overflow, the result will tend to be
rather confusing and catastrophic. The effect of the overflow may not be
detected for some time. When the anomaly finally becomes evident, it may appear
within otherwise unrelated sections and be un-repeatable.
Therefore, care must be taken when writing a model to avoid situations which may overflow a thread's stack. The thread-local variables are intended to typically hold only a few small scalar variables. Under normal cases, it is very unlikely that much of the available stack will ever be used. The possibility of stack overflow is eliminated by responsibly using the local variable sections.
However, when larger variables are needed, do one of the following three things:
Instead of declaring:
A = (int *)malloc( 5000 * sizeof(int) );
Malloc'd memory comes from the heap not the stack, so this is a safe way to circumvent any memory limitations. Heap is unlimited. It grows as needed.
Such variables are allocated from the heap not the stack. They do not affect the stack.Or,
TRIGGER_THREAD_STCKSZ works just like TRIGGER_THREAD. The first three parameters are the same. The final (extra) parameter of the TRIGGER_THREAD_STCKSZ function sets the thread's stack-size in bytes.
This enables you, the modeler, to specify the needed stack space for specific threads. For example, it often happens that most model threads are very small, but one thread will have large programs running under it, so we set that thread's stack-size to perhaps 4-MB, or 16-MB, etc.. You could even use this function to make smaller-stacks for lighter-threads, if it is consistent with what is needed.
Under Linux for example, there is no such limitation for POSIX threads. Yet the threads are very memory efficient, because their stack is initialy set small but is automatically expanded (in 4kB-blocks) as needed.