Symptoms
After updating Impact Acquire to version 2.32.0 or greater while a version smaller than 2.32.0 was running before a client application no longer terminates. When attaching a debugger it can be seen that the function DMR_ImageRequestWaitFor never returns.
Cause
The default value of the property ImageRequestTimeout_ms has been changed according to the following table:
| Impact Acquire version | Default value of the 'ImageRequestTimeout_ms' property |
|---|---|
| < 2.32.0 (May 8, 2019) | 2000 ms |
| >= 2.32.0 | infinite |
This was done as in the past the timeout caused by this property was a always a great source of confusion because effectively there are 2 timeouts affecting the overall behavior of the acquisition engine as explained here: Timeouts
This change however has potential effects on applications not dealing with abort conditions properly. Applications not cleaning up e.g. by calling DMR_ImageRequestReset AND calling DMR_ImageRequestWaitFor with an infinite timeout AND not explicitly setting the value of the ImageRequestTimeout_ms property might suffer from this change as now by default a buffer never times out. So in an application where e.g. triggered images are no longer arriving (because the trigger signal has already been switched off) now the application might wait forever when shutting down while previously the application did shut down eventually after some time.
Resolution
The affected application can be changed
Several things can be done to overcome potential problems. All the guidelines presented here should be followed in any case and not just because of the problem described here!
- Always make sure no more buffers are active when shutting down the application
- If the application still actively waits for buffers with an infinite timeout but no more buffers are delivered by the device call DMR_ImageRequestReset from a separate thread to unblock the DMR_ImageRequestWaitFor function
- Do NOT call DMR_ImageRequestWaitFor with an infinite timeout but with a reasonable timeout interval of e.g. 200 ms and call it in a loop. Whenever no new buffer became ready simply call it again. This way the capture thread stays responsive and can be terminated in a worst case after one full timeout interval has elapsed even without the need to call DMR_ImageRequestReset in parallel
- Do NOT rely on default values, but explicitly set the value of ImageRequestTimeout_ms if desired (if all the previous guidelines have been followed there should hardly be a reason for this one)
The affected application can not be changed
If the affected application can not be modified the previous behavior can still be restored if a setting is loaded by the application(from a file or (on Windows®) from the Registry). When this is the case simply edit the ImageRequestTimeout_ms parameter by removing the default flag and/or the actual value of the property:
Setting in a file
In the setting XML file locate the property:
<Property name="ImageRequestTimeout_ms" default="1" position="16" flags="7" size="1" formatString="%d ms" valType="1"> <Value index="0" val="2000 ms"></Value> </Property>
You can change it e.g.by removing the default flag like this to restore the previous behavior:
<Property name="ImageRequestTimeout_ms" default="0" position="16" flags="7" size="1" formatString="%d ms" valType="1"> <Value index="0" val="2000 ms"></Value> </Property>
Setting within the Windows® Registry
