| 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: GW status |
| From: | Stephen Lewis <[email protected]> |
| To: | Jeff Hill <[email protected]> |
| Cc: | "'Amedeo Perazzo'" <[email protected]>, "'Core-Talk'" <[email protected]>, "'Ernest L. Williams Jr.'" <[email protected]>, "'Dirk Zimoch'" <[email protected]> |
| Date: | Tue, 04 Aug 2009 15:25:20 -0700 |
Fundamentally EPICS is asynchronous and all client applications should have been and should be written strictly to this assumption when using ca_put. As I recall, ca_put_notify was added to allow sophisticated client to build up a type of 'transaction' capability.
In the case of the motor record (the case that triggered all this investigation), when the monitor on the DMOV field goes 0->1 then you can trust all the other field values. Everyone up to now must have known this, otherwise all the instances where there is no gateway would have given poor results.
On 4 Aug, 2009, at 3:11 PM, Jeff Hill wrote:
1. PCAS was unable (before the patch) to handle subscriptions duringthe time that ca_put_callback was being processed.