LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Add ni-rt.ini setting for thread stack space

Status: New

I have been recently tasked with porting a Windows DLL to Phar Lap. So, code is not my own, there's a lot of it, and the DLL is crashing with stack overflows. Recursion is not a problem here, so it's obvously a local variable space. The default thread stack size is 128k, which is a bit on the low side. An ini setting that would allow to increase this would be most welcome. Especially if you're not getting errors in your own thread, but in the LabVIEW ones.



1 Comment
Active Participant

I don't really like the idea increasing the default stack size for LabVIEW threads (or even encouraging you to do so on by creating the documented ini token you propose), as there are many of these threads created without the user's direct control, and the vast majority of them do not need such a large stack.  To be honest the vast majority of them don't even approach 128k in normal usage.


There are a couple of alternate solutions I would prefer over such a token.


Since you're writing your own DLL, you can use the Windows API's to explicitly create a thread, and stack size is a parameter to those APIs.  Then, send a message from the LV thread to your own thread to do the stack-hungry operation.  See etc.


Also, 128k is fairly generous even for stack-hungry applications.  If you have stack variables using up 10's or 100's of kB of stack, you may be better off refactoring those large buffers into the heap, rather than exposing yourself to this sort of issue again in the future.