DigitalOutput with finite sampling can indefinitely prevent notifications from other observables

[RoboDoig]

A common DigitalOutput pattern (also shown in the docs) is to trigger the output within a SelectMany, for example to update buffer and sample rate parameters dynamically in response to different inputs. For example:

Consider the workflow:

The first KeyDown triggers the SelectMany and the DigitalOutput. If the first KeyDown is pressed several times (before the FiniteSample task has completed), both KeyDowns will eventually stop producing notifications. I wonder if the task.WaitUntilDone() blocking call has something to do with this, or the nidaqmx interface is excepting silently.

Interestingly, if we use the Shader package KeyDowns instead this behavior is not observed, although notifications from the KeyDown that trigger the SelectMany are delayed until the DigitalOutput task has completed.

[glopesdev]

both KeyDowns will eventually stop producing notifications

@RoboDoig This is actually a quirk of the Windows OS. I am assuming both Shaders key presses and Windows key presses are getting blocked temporarily by a lock on DAQmx, since it needs to control exclusive access to the shared DAQ resource.

Assuming this is the case, then we actually know that Windows OS will "unhook" an application callback that "hangs" for too long on the mouse interrupt (you can observe and reproduce this by pausing VS to debug a workflow with an active KeyDown and continuing to move the mouse while the debugger is paused).

Separate from this, we indeed might want to consider providing a way to explicitly indicate whether WaitUntilDone should be called, so I will keep the issue open until we have a decision on this.