Bug 1171 - Closing PulseView during a decode run doesn't actually close PulseView
Summary: Closing PulseView during a decode run doesn't actually close PulseView
Status: RESOLVED DUPLICATE of bug 1174
Alias: None
Product: PulseView
Classification: Unclassified
Component: Protocol decoding (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-20 16:33 CEST by Uwe Hermann
Modified: 2018-04-21 00:25 CEST (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Hermann 2018-04-20 16:33:20 CEST
How to reproduce:

 - Start PV, load dcf77_480s.sr.
 - Add the DCF77 decoder and let it run for 2-3 seconds to check that it's decoding properly.
 - Now (while the decoding is still running) close PV by clicking the X icon on the window.
 - The UI will disappear, but in the xterm PV was started from you don't return to the shell. PV apparently continues the decode under high CPU load, and only as soon as it's finished will PV actually close and return control to the shell.
Comment 1 Uwe Hermann 2018-04-20 18:00:07 CEST
Additional info: This doesn't happen with acquisitions, only decoder runs. I.e., if you have a 1T/1MHz fx2lafw acquisition running and press X to close PulseView, it'll close immediately and return control to the shell. It won't try to finish the currently running acquisition.
Comment 2 Soeren Apel 2018-04-20 19:07:46 CEST
That's due to the DecodeSignal::DecodeChunkLength being fed to srd_session_send(), which is a blocking call. I only see two possible solutions here:

1) reduce the DecodeChunkLength (currently 256 * 1024 bytes) or
2) make srd_session_send() nonblocking and provide an interrupt mechanism
Comment 3 Uwe Hermann 2018-04-21 00:25:46 CEST
Turns out this was also fixed by the same fix that also fixed #1174, closing as duplicate.

*** This bug has been marked as a duplicate of bug 1174 ***