Channel access monitors: draft for discussion. #24
Conversation
I wasn't sure of the lifetime of the object that got returned. If you yield a
or we could: @dataclass
class Updater:
func: Callable
async def __call__(self, value):
await q.put(lambda: self.func(value))
value_monitor = camonitor(pv, Updater(channel.update_value), format=FORMAT_TIME)
...
meta_monitor = camonitor(pv, Updater(channel.update_metadata), events=DBE_PROPERTY, format=FORMAT_CTRL)
while True:
channel_updater = await q.get()
channel = channel_updater()
yield channel
Metadata updates are pretty rare though aren't they? They only happen once on old servers, and only on EGU/PREC/HIGH... changes on new servers? |
I wondered if there was some such consideration.
Good point.
Yes, something like that. |
|
How important is it that only the updates are emitted by the generator? My refactor is presenting a complete It might have been that Tartiflette decided what needed updating, but it does not appear to. The documentation isn't very detailed on this sort of thing. |
|
Ah, I missed that. I designed that in as it seemed pretty crucial for performance that only the fields that changed in a subscription were sent. Otherwise we're doubling the payload of every message, which doesn't seem great... |
Now maintain state in one object but yield a new object containing the relevant updates each time. Add a single cainfo request to determine whether the channel is writeable.
|
Well this has been a journey. I think this is now behaving correctly, but it is quite involved. There are a couple of naming questions, and one test is failing because the first channel update is not a complete structure now. |
Although the value itself should not have changed, the way it is formatted may be changed by a meta update, so it is simplest to resend the value.
|
There is another detail: we need to send a new value if the formatter changes. I already see an example where an enum is dispatched as a number but then a metadata update changes the formatter but does not resend the string value. We could check if the formatter has changed before sending a value, or we could send a value for each metadata update since we expect these to be infrequent. I've chosen this for now. |
That sounds reasonable |
|
Looks good to me, are the tests passing? I must update this repo to github actions too... |
|
I just updated the final test. Yes, we could do with the tests running here. Last thing: we have a |
|
Hmm, could we merge the first update and second update together with the cainfo writeable? I'm not a big fan of that initial value update without metadata, so I think it's worth waiting a couple of milliseconds to present data + metadata in the first update |
|
The test relies on update 1 being value and update 2 being meta. This appears to happen, but I am not sure that we can rely on it. If we can, we could wait for the first two updates and create a full structure first. Otherwise we have to think of a way to pause the first update until both monitors have returned. I think we can assume that if one monitor returns then the other will. |
How about |
We could keep squashing updates until we have had both a time_value and meta_value update? |
|
Dropping updates, presumably. I mean drop the older updates until we have one of each and we are ready to start. |
|
Yes
…________________________________
From: Will Rogers ***@***.***>
Sent: 24 June 2021 10:44
To: dls-controls/coniql ***@***.***>
Cc: Cobb, Tom (DLSLtd,RAL,LSCI) ***@***.***>; Review requested ***@***.***>
Subject: Re: [dls-controls/coniql] Channel access monitors: draft for discussion. (#24)
Dropping updates, presumably.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub<#24 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB2ZDZGHE56DUA76TLLFD5DTUL47XANCNFSM465U56TA>.
--
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
|
|
OK, done? |
See #22.
Plenty to discuss here:
valuefrom theFORMAT_TIMEmonitor. We couldtimestampoutside of the class (as I have done)timestampinside the classunitsorenumsorprecisionchange then we do want to create a new oneAny thoughts?