EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: V4 Data Types: Request for tagged unions
From: Ralph Lange <[email protected]>
To: [email protected]
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 16 Jun 2005 15:26:27 +0200
Benjamin Franksen wrote:

On Thursday 16 June 2005 12:55, Benjamin Franksen wrote:
On Wednesday 15 June 2005 23:12, Andrew Johnson wrote:
To step back a little: I don't understand why your states have
parameters, and what you could do with them - presumably I can't
put a CA monitor on a member of a tagged union (what happens to the
monitor when the state changes and the member no longer exists?).
It must disconnect, indicating that the value in question no longer
exists. Note that a similar question must be answered for the case of
adding/removing views. Here, too, the client will need to receive
notification that a certain value is no longer available. We could
make this a dedicated event type so that clients can react in a
generic way to such conditions.

Let me state this more precisely:

The very idea of a tagged union implies that independent read or write access to properties subordinate to a certain tag hardly makes sense. I cannot change, nor query, the scanRate of a record, as long as I am not certain that the tag is 'Periodic'. However, subscribing to merely a certain subordinate property might reduce system load.

The problem is that changing the tag independently brings the other subordinate properties to an undefined state and this is something we can't handle because we don't have a representation for "no value here". Thus, at least write access must provide all values every time (i.e. tag + add. properties), while reading and subscribing to either tag only or other properties can be allowed but must fail in case of unavailability.
Hm. I don't see any problem with my original idea to have the write traversal for a tagged union (exactly like the read traversal) first provide the tag and then only the properties that are valid for the new tag value. Valid write operations would succeed, invalid operations would fail, no meaningless properties being provided in the process.

Ralph


Replies:
Re: V4 Data Types: Request for tagged unions Benjamin Franksen
References:
RE: V4 Data Types: Request for tagged unions Jeff Hill
Re: V4 Data Types: Request for tagged unions Benjamin Franksen
Re: V4 Data Types: Request for tagged unions Benjamin Franksen

Navigate by Date:
Prev: Re: V4 Data Types: Request for tagged unions Benjamin Franksen
Next: Re: meeting in July / ca interface specification Doug Murray
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: V4 Data Types: Request for tagged unions Benjamin Franksen
Next: Re: V4 Data Types: Request for tagged unions Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·