Closed aschulm closed 9 years ago
It's a misleading function name, carried over from the Saleae API docs. When your capture finishes, capture_start will return, but this probably isn't the desired behavior in most cases. I have literally one script using this stuff right now, so feel free to change to a more sane API and I'll update my side.
Well my bigger concern is the fact that your documentation says that command should return immediately and it doesn't. You also already have the "capture_start_and_wait_for_finished" which does the blocking start.
I found the non-blocking start useful.
My plan is to just add a wait_for_ack parameter to _cmd()
Huh. Clearly I thought about that and it doesn't behave as expected. A bit distracted today, sorry for the misinformation before.
Will saleae eventually send an ack for the capture / will this lead to an out-of-band ack at some point we have to deal with?
On Wed, Sep 9, 2015 at 4:31 PM Aaron Schulman notifications@github.com wrote:
Well my bigger concern is the fact that your documentation says that command should return immediately and it doesn't. You also already have the "capture_start_and_wait_for_finished" which does the blocking start.
I found the non-blocking start useful.
My plan is to just add a wait_for_ack parameter to _cmd()
— Reply to this email directly or view it on GitHub https://github.com/ppannuto/python-saleae/issues/3#issuecomment-139037252 .
No, capture never returns an ACK.
"Socket Command: capture This command starts a capture. It will return NAK if an error occurs. Example: capture"
I decided to add a wait_for_ack parameter to _cmd() with a default of True, and I only modified the capture_start() _cmd() call to not wait for ack.
capture_start() runs _cmd() which waits for an ACK
I guess we could consider a parameter to _cmd that specifies if it should wait for ACK or not, or we can just build the _send right into capture_start(), but that's kinda hacky.