Zero length length requests, EPICS upgrades, and cothread

[<michael.abbott@diamond.ac.uk>]

This is a question for users of cothread.catools.


Some years ago there was an EPICS codeathon where we extended CA so that a request for zero length waveform would be interpreted by the server as a request for the "natural" length of a waveform.  The intent was that the .NORD field of waveform records would be respected, but this change to record support has only recently been implemented.

At some point between 3.14.11 and 3.14.12.3 (DLS is in the process of migrating to the latter version) it seems that waveform record support for NORD length requests has been implemented.  Of course this is a change in behaviour, and inevitably something is going to break.

Up until this change it's a fairly safe bet that almost nobody has been paying any attention to NORD, and so for example interactions which change it (such as performing a short caput to a waveform) have had no consequential effect.  My attention has been drawn to the fact that certain cothread applications now break!

It's unfortunately all too easy to reset the NORD of a writeable waveform to the wrong value by mistake, for example by performing something like 'caput $PV $value', which will truncate $PV.NORD to 1.  Downstream applications monitoring $PV now see it shorten.  Arguably this is a bug in the specific implementation of $PV itself (for example in my own drivers if a writeable waveform is fixed length I prevent NORD being overwritten), but because nobody has paid attention to NORD up to now, this is a new problem.

The problem is that when cothread performs a caget() or camonitor() request the default data length that is requested is zero, and so when migrating from a .11 to a .12 server we can suddenly see the length of received waveforms shorten (or cease to be waveforms altogether)!  I am now faced with a bit of a dilemma, so I ask all users of cothread to please give me your opinions to the following question:


QUESTION: What should be the correct *default* result length when using cothread to perform caget() or camonitor() on a waveform?

A. The "natural" length, encoded as zero: this returns NORD elements on a .12 and above server, but NELM elements on older version of EPICS.  (This is the current default.)

B. The "full" length, which for a waveform is NELM elements.


I am proposing to make the following *incompatible* change: the default result length (encoded by the 'count' parameter to 'caget' and 'camonitor') will change from 0 ("natural" length) to "full" length, and if the "natural" length is wanted it will be necessary to explicitly specify 'count=0' as an argument.

Unfortunately I'm proposing one incompatible change in order to manage the impact of another incompatible change which was meant to be fully backwards compatible.  Sigh.  The irony of compatibility!  Please shout if you think this is a bad idea...


While I'm breaking compatibility, maybe the result from a waveform of "natural" length 1 should be encoded as an array rather than as a scalar?  Also, are there any requests for changes and fixes to cothread?

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom