DAQmxbase blocking issue (mac os)

[Ageradi]

Thank you for your reply. I believe we are not talking the same language.

Have you tried doing exactly what I listed above (with the blank VI in a dummy .framework)? What exactly is happening when you do that?

I can't. As mentionned before, I don't have labview installed. So I can't create VIs. Plus, I don't know how to put a VI in a .framework.

What I currently do is to place a call to DAQmxBaseLoadTask() part of my initialization process. I actually try to load a dummy task. I found it to be the fastest.

During that time I display the initialization box. After that, when the initialization of my app is finished, any other call to DAQmxBaseLoadTask() will be fast. I believe this achieves the same as what you recommend. What advantages would there be to having a blank VI in a .framework folder?

Also, how exactly are you determining that some other thread is hanging?

Well, as I mentionned, I am developing an Objective-C application with Xcode. So, knowing which thread is hanging is really really really easy. I have acces to all the threads, I can debug them, see the assembly code, execute any of them step-by-step, etc.

The waiting thread is a thread labelled com.apple.root.default-priority and is lost in a mach_wait_until() call. The until condition (which I have a hard time guessing from the assembly code), never occurs. Additionnaly, I can tell that this thread does so from the moment I first call down to the DAQmxBase framework. It is waiting like that for the entiere life of the application.

[AdamKemp]

"What advantages would there be to having a blank VI in a .framework folder?"

I don't mean having a blank .vi file in a .framework folder. I mean building a VI into a .framework in the same was as DAQmxBase's .framework (which is written in LabVIEW). The advantage would be that calling a blank VI would be faster than whatever DAQ call you're making, and it would have the same benefit of preventing the hang on exit. You mentioned that calling into DAQmxBase during initialization caused serious performance problems. Calling into a blank VI should not have those performance problems.

If you can use a debugger to determine for sure exactly which version of the LabVIEW runtime is being loaded by DAQmxBase and tell me then I can build this .framework for you.

"The waiting thread is a thread labelled com.apple.root.default-priority and is lost in a mach_wait_until() call. The until condition (which I have a hard time guessing from the assembly code), never occurs. Additionnaly, I can tell that this thread does so from the moment I first call down to the DAQmxBase framework. It is waiting like that for the entiere life of the application."

Again, just because a thread appears to be doing nothing thorughout the life of a process does not mean that it is "hung". It is not uncommon to have threads which rarely do any work. The definition of "hung" is more like "cannot possibly make progress", not "appears to be doing nothing". The thread you're seeing (which is not even a LabVIEW thread) is probably just waiting to be told to do something, and maybe it never has anything to do. At some point it will go away when the process is terminating.

The hang you're seeing is caused by the UI thread blocking, not some other thread. Those other threads are totally unrelated to this issue. You should ignore them unless they're actually crashing,

Let me know which runtime engine is being used by your DAQmxBase, and I will build a .framework with a single entry point for you to call in initialization. It will just be something like "InitializeLabVIEW();".