NIDAQmx Base and Cocoa: Creating a NIDAQ task stops my application from quitting

[Tangle]

Yes, I get the behaviour if I just place a function arount the example and then call the function.

You are starting to go around in circles.  Perhaps read the read the original post again.  It does not lock up during the code.  It lock up after when the applcaition is trying to exit and all the LabView filled threads are gettings spawned (see previously attached stack trace).

The original post also says that I have already cut the code back.  The problem is that if I cut it back any further then NIDAQmx Base is not being called at all.  Even if all I do is allocate a task and then immediately clear it, my applcation will hang on a LabView function when I try to quit later on and seemingly start spawning an endless number of threads filled with labview processes.  The longer I leave it hanging the more duplicate (apparently) labview threads I see when I pause to view the stack.

[Steven_T]

Hello,

I'm from the DAQmx Base team, and I'm working on reproducing your problem. Your stack trace gave me quite a bit to go on, but I have a few experiments that I want to try as well.

Thanks,

Steven T.

[Dominik-E2]

Hi Lee,

Could we get a little more information from you? Mainly, what version of OS X do you have? Also, what version of X code? Something else that would help in reproducing the issue would be for you to post the simplest project that shows the behavior (likely, your first post inside a project). Is this issue a significant deterrent in you moving forward with the development of your project or can you code other parts while we troubleshoot?

[Tangle]

Dominik and Steve,

Thank you for continuing to pursue this.

I have pared my project away to it's simplest form that produces this hanging problem (see attached).  In doing so I realised that I made an error in my last post.  Wrapping the example code is a simple obj-c object on the main thread does not produce this behaviour.  Wrapping it in an NSOperation and running it on a concurrent thread does (I have also tried manually configuring and detaching NSThreads and get the same behaviour).  I appologise for my mistake, I am sure it contributed to difficulty in you reproducing the issue.

From my application's point of view it makes no sense for me to run NIDAQ sampling on the main thread as sampling is continuous and would prevent user interaction by holding up the main thread.

I am using xCode 4.4.1 on OS X 10.7.4.  Using the attached project follow these steps to reproduce the problem:

1) Compile and run

2) Press the "Start" button.

3) Wait for sampling to start (data will be printed to the console).

4) Press the stop button.

5) Quit the SimpleNIDAQ application.

6) Experience hanging problem (I hope!) with a stack trace similar to the attached.

Note that if I change the while loop to run for a finite period of time instead of checking for isCancelled, I still get the hang occuring upon quitting.

I should also point out that this is the entire NI example code wrapped in an object.  I can delete the while loop and the lines before it all the way back to (but not including):

DAQmxErrChk (DAQmxBaseCreateTask("",&taskHandle));

 and still produce the hang.  If I don't create a DAQmxBaseTask, the application runs as expected and quits normally even with other non-NIDAQ realted work being done by the NSOperation.

Currently this problem has not stopped me continuing on the project.  Over the the last week I have been able to work on other parts of the project.  However, I think it won't be long (about another week or so) until I think this issue will halt development.

I hope this information helps,

Lee.

[Dominik-E2]

Hi Lee,

What you posted was very helpful. Steven has been able to reproduce the hang you are seeing. As of now, he is still trying to characterize the details of the behavior. We will keep you up to date on any further progress we make or if we find a work-around. Thank you again for the detailed description.

Regards,

Dominik

[Tangle]

Dominik and Steve,

Have you had any progress on this problem?

Thanks

Lee.

[Dominik-E2]

Hi Lee,

It looks like the behavior stems from the fact that the C API is ultimately a LabVIEW dll and the LabVIEW runtime engine has some compatibility problems with Cocoa. Right now, I am in the process of checking on the status of a work-around with another member of R&D to see if we have a way to avert the hang up. As soon as I hear back from him, I will, of course, relay the information to you.

[Dominik-E2]

Hi Lee,

Have you tried simply calling exit(); as a way to terminate the program after your cleanup is complete? Does the same hangup persist?

[Tangle]

Dominik,

It's not clear what you mean.  Do you mean that I should try calling exit() after data collection cleanup or after the user quits?

Calling after data collection does not fit the application design, as the user will want to continue using the applcation.

Cocoa does it's own cleanup upon quitting, which should not be skipped in this case.  I will see if I can intercept the quit process, do that cleanup manually and then call exit().  I'll get back to you.

Thanks

Lee.

[Dominik-E2]

Hi Lee,

Have you had any success with the exit() function? I realize that this probably won't fulfill your use case, I just wanted to see if you were able to avoid the hang-up at all.