QSRV 2

[mdavidsaver]

The rewrite of QSRV using PVXS.

Current Status: Alpha. Testable, but lacking features. Principally PVA links.

• [X] Single PV access (aka. RSRV equivalence)
• [X] Group PV access
• [ ] PVA Links

My compatibly target for the QSRV functionality is Base >= 3.15 for Single PV, and >= 7.0 for Group PV. Lack of support for Group PV with 3.16 is only a case of my not spending the time to add #ifdefs and testing.

Following the pattern of pvget -> pvxget, this branch adds a softIocPVX executable.

QSRV functionality is added to the existing libpvxsIoc.so library when available (aka. > 3.14). So the build time instructions don't change. However, while the PVXS server is started during iocInit, at the moment the database interactions must be explicitly enabled by setting:

export PVXS_QSRV_ENABLE=YES

If all goes well iocInit() will print:

INFO: PVXS QSRV2 is loaded and ENABLED.
Starting iocInit

Open Questions:

• What should interoperability with QSRV be? My current goal is to allow both to be linked and run without ill effect (apart from duplicate PV warnings). Is this the way to go?

TODO:

• [X] Interoperability with QSRV 1. (avoid symbol and DTYP name conflicts)
• [X] Fix softIocPVX paths w/ Base 3.15
• [X] info(Q:time:tag, ...
• [x] Add display.form and display.precision. cf. epics-base/pva2pva#19
• [X] Test for use of alias names in groups. cf. epics-base/pva2pva#14
• [X] Test DISP handling. cf. epics-base/pva2pva#33
• [X] Test w/ some channel filter. cf. epics-base/pva2pva#41
• [X] Verify control of field order w/ putOrder. cf. epics-base/pva2pva#53
• [X] Figure out how to test put logging. cf. epics-base/pva2pva#13
• [X] Make use of dbServer. cf. epics-base/pva2pva#18
• [ ] NTEnum assign by string? cf. epics-base/pva2pva#26
• [X] Test for epics-base/pva2pva#51
• [X] dbLoadGroup() w/ macros
• [X] Test non-atomic group access
• [X] Populate record._options for monitor/get
• [X] Test dbNotifyCancel()
• [X] Include pvxsIoc in python build
• [X] Documentation...

pva2pva issues already addressed:

• Addition of a $ modifier is enough to trigger long string handling for link and string fields. cf. epics-base/pva2pva#17 and epics-base/pva2pva#22
• structure mapping works as intended/documented. cf. epics-base/pva2pva#47 and epics-base/pva2pva#49

Added features:

• dbLoadGroup() accepts macros.

[AppVeyorBot]

:x: Build pvxs 1.0.851 failed (commit https://github.com/mdavidsaver/pvxs/commit/606e2a77a3 by @mdavidsaver)

[AppVeyorBot]

:x: Build pvxs 1.0.856 failed (commit https://github.com/mdavidsaver/pvxs/commit/5d8737676b by @mdavidsaver)

[AppVeyorBot]

:x: Build pvxs 1.0.859 failed (commit https://github.com/mdavidsaver/pvxs/commit/b8d6bcddf0 by @mdavidsaver)

[AppVeyorBot]

:x: Build pvxs 1.0.861 failed (commit https://github.com/mdavidsaver/pvxs/commit/71e3ea4120 by @mdavidsaver)

[AppVeyorBot]

:x: Build pvxs 1.0.869 failed (commit https://github.com/mdavidsaver/pvxs/commit/1aba651cea by @mdavidsaver)

[AppVeyorBot]

:white_check_mark: Build pvxs 1.0.869 completed (commit https://github.com/mdavidsaver/pvxs/commit/1aba651cea by @mdavidsaver)

[ericonr]

Hi! I got to this PR from the EPICS Collab Meeting :) I am using it in one of our new IOCs which I'm currently developing and testing, and it seems to be working fine. I have tested puts, gets and monitors from scalar (long* and a* records) and waveforms (aa* records with FTVL being SHORT, LONG or DOUBLE).

Are there any attention points I should focus on? Things to stress test?

[mdavidsaver]

Are there any attention points I should focus on? Things to stress test?

This is a good question for which I don't have a simple answer. The areas where I can imagine problems include:

• Feature completeness.

Especially the odd corners of group mappings and other info(... tags. (Some of which I may not have intended)

• Performance with many clients.

I expect that performance with a single client will be similar to QSRV1. However, the PVXS client and server don't use as many threads as pvAccessCPP, so there is a potential for performance regression with a large number of clients.

• Resource leaks

This was (and is) a common bug with the pv*CPP modules. Particularly those were the "leak" is cleaned up on exit, but grows without bound in a long running process. The kind which are "invisible" to tools like valgrind.

[AppVeyorBot]

:white_check_mark: Build pvxs 1.0.879 completed (commit https://github.com/mdavidsaver/pvxs/commit/4bf6e46f5a by @mdavidsaver)

[mdavidsaver]

• Resource leaks

This was (and is) a common bug with the pv*CPP modules. Particularly those were the "leak" is cleaned up on exit, but grows without bound in a long running process. The kind which are "invisible" to tools like valgrind.

I have added a set of three IOC shell commands to help with monitoring long term resource usage: pvxrefshow, pvxrefsave, and pvxrefdiff. Similarly named commands are provided by pva2pva. These commands read and compare a set of per c++ class instance counters. Checking these counters should make it apparent if certain types of slow memory leaks are happening.

eg. the delta after a client monitoring one PV has disconnected.

epics> pvxrefdiff 
MonitorOp       = -1
ServerChan      = -1
ServerConn      = -1
ServerMonitorControl    = -1
SingleInfo      = -1
SingleSourceSubscriptionCtx     = -1
StructTop       = -3

[mdavidsaver]

At this point I am satisfied that with QSRV2 runtime disabled (the default) current users will not see a regression. Even in the pathological case where both libpvxsIoc and libqsrv (from pva2pva) are loaded at the same time.

So this meets my criteria for merging and releasing this code as a "feature preview".

[AppVeyorBot]

:white_check_mark: Build pvxs 1.0.886 completed (commit https://github.com/mdavidsaver/pvxs/commit/1a05e2338f by @mdavidsaver)

[mdavidsaver]

Merged.

Please continue to report test results here. Open issues for any bugs encountered.