LV 2013 VI hangs on zmq_term.vi call if "reap? = False"
LabVIEW bindings for the ZeroMQ project
Brought to you by:
mjasperse
Menu
▾
▴
https://dl.dropboxusercontent.com/u/19403476/PUB-SUB%20Simple%20Example.vi
Run the VI. Stop it using the "Stop" button. It hangs on the call to zmq_term.vi. Set "Reap Context" to True and run/stop it again. It exits normally.
LabVIEW's total lack of forward-compatibility is very annoying. I'm running 2010 and 2012, could you export for one of those versions?
https://dl.dropboxusercontent.com/u/19403476/PUB-SUB%20Simple%20Example_lv12.vi
The error is in your program, you are passing 0 (NULL) to the top zmq_close call, which trivially succeeds, but term hangs because there is an unclosed socket. The wire connecting the socket breaks in the "<Stop Application>" case of the top event structure.
I have modified zmq_close to return ENOTSOCK when passed NULL.
Last edit: Martijn Jasperse 2013-10-24
Oh, duh. Thanks for the help. Incidentally, if I run the VI as it is written with v1.5.3, zmq_term.vi tries to execute and hangs on an incoming error. I assume that's the behavior you want, but given that hanging the entire application is a potential outcome of the "execute anyway" paradigm, I recommend changing the VI to use Standard Error Handling (where it does not execute on an incoming error and propagates that error to its output).
Yes, it's probably worth dropping "execute anyway". That's mostly a hangover from before when the automated clean-up on abort/unreserve did not function correctly.
I think I'll add a helper VI that detects ETERM and (optionally) removes it from the incoming error, for the user to call before zmq_close, etc, because obviously you don't want ETERM stopping that from firing.