-
Notifications
You must be signed in to change notification settings - Fork 9
Exec testFail instead of exit(3) if channel is not connected #85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I am not sure if testFail() is appropriate in the connection callback, as it is not clear which test are we failing. It looks like there is already a test which should fail if monitor is not connected, so it seems to me that removing exit() statement, having some sort of log message in case of failure, and moving event.signal() to the end of the callback function would be sufficient. @anjohnson, what are your thoughts? |
There looks to be exactly one set of tests which could call this routine, implemented around line 210 of this file. Nothing else uses that However the epicsUnitTest API expects the number of test results generated to always be the same whether they fail or succeed, so replacing the The author presumably added the The best way to handle that situation is to make the Another solution would involve moving the following tests that depend on If you're seeing this test fail frequently (presumably on a heavily-loaded machine) I would also increase the timeout parameter to the Thanks! |
To reduce the risk of timeout on heavily loaded machines.
Thanks both. Please see if f903316 looks OK. If it does, I can also drop the initial commit. I did also add a timeout increase, but I haven't tested if this helps against my spurious failures; I was mainly running into those as part of some other work that I now don't have a strict need to re-run the tests for. I can drop also this commit. |
Should something more be done here @sveseli @anjohnson ? |
The CI builds for RTEMS don't like the member assignment on line 141, I think that may need moving into a constructor to be accepted by their older compilers. I haven't looked closely at the code again this time, I will once those builds pass. Sorry for the delay responding… |
Resolves #84