Sandboxed execution

[spatry]

It would be really nice is the IDE, and my program were not the same process.

Especially when dealing with 3rd party DLL's, it would really be nice if a bad pointer or misallocated buffer in a DLL didn't crash my whole development environment, but instead just took out the running program.

[elset191]

Sounds like a duplicate of Execute DLL in sandbox

[spatry]

While related, I don't think this is a duplicate. Both of these are trying to address the same issue. However, they are different solutions to the problem. As mentioned in the comments of the other idea, isolating the DLL alone is likely to incur a large performance penalty. This would be much more in line with how Google Chrome handles pages (and likely how other IDE's handle debugging).

[AristosQueue (NI)]

Unlikely that we will go down this road any time soon. Yes, making it a separate process would be nice when you hang and have to kill the process. Obviously we could do it -- we do it for RT which isn't even on the same machine! 🙂

The problem is desktop debugging. LabVIEW deals with a lot of data, and we do try to provide a pretty rich debug experience compared to other programming environments. To do some of our "suspend and rerun" tricks or probes for very large waveforms would require a lot slower communication from the running process to the debugging process. We are somewhat concerned that our debugging experience would degrade noticably.

If it was a huge issue for many customers, we'd prioritize researching if there's a way to do it without performance hits, but as of right now, we don't see many users falling into this case.

I'm going to recommend that we leave this idea open to see if it accumulates more kudos, but I doubt that it does.