On Samstag, 13. Juni 2009, Andrew Johnson wrote:
> Michael Davidsaver suggests we make the changes in the attached patch,
> which moves alarm.h from src/dbStatic to src/ca and puts the static alarm
> strings into libca.
I think it is questionable whether it is really an improvement. Alarm stati
and severities are a central concept used all over the place in the core of
the EPICS database, moving this stuff to CA doesn't sound right to me. What
is the gain?
> We've never really got the alarm enums right; there are equivalent
> definitions in src/db/menuAlarmStat.dbd which must match alarm.h, and we
> currently have the header alarmString.h which currently instantiates a
> global alarm string array into whatever file it's included by. This is
> used both internally (by catools and cap5) and externally (by MEDM, ALH,
> etc).
I think you have once proposed to simply use strings for the alarm status
and I think this is a step in the right direction. What makes this idea
less attractive is that we'd have to send the whole string over the network
each time the status is demanded. This could be avoided if EPICS offered
support for internalized, immutable strings; let's call them 'atoms' (just
to have a name). The idea is that you can register a string and get back a
unique integer value that can be sent around at a constant small cost,
similar to the current EPICS enumerations. But in contrast to the latter,
new atoms can be created at runtime and they do not have to be numbered
sequentially. This would be ideal for things like alarm status and other
kinds of enumerations which need to be extensible at runtime. In fact, it
is a safe bet that a huge majority of strings in an IOC are (at least
conceptually) immutable and so could use this feature. You might argue that
you loose the (runtime-) 'typing' that is associated with enumerations,
i.e. we can recognize invalid enumeration values. However, keeping a list
(array) of valid atoms around and checking whether a supplied atom is an
admissible value would be as easy or hard as it is now.
As to implementation of such a feature, this would be easy in a single
process (just use a hash table), but of course we want the returned
identifier to be unique across a whole site, which is not quite as trivial.
Off the top of my head I see three ways:
(a) centralized service
Easiest to implement, but single point of failure, high startup cost, but
can be amortized by caching on the IOCs and clients.
(b) distributed service
Like (a) but no central server, instead each IOC replicates what all the
others have, clients may cache. Ambitious: no idea whether there are
efficient algorithms for the synchronization; extra points for detection
and recovery from inconsistencies ;-)
(c) cryptographic hash
Most elegant, no communication overhead because string->atom is just a pure
function (no side effects, no dependency on order of calls). But may be
impossible to compress into 32 or even 64 bits with a negligable
probability of collision. I am not enough expert to judge.
In any case, adding something like this to EPICS would need serious
addition(s) to the CA protocol, although not necessarily incompatible ones.
Cheers
Ben
- Replies:
- RE: Patch: Move alarm.h and rename alarmString.h Davidsaver, Michael
- References:
- Patch: Move alarm.h and rename alarmString.h Andrew Johnson
- Navigate by Date:
- Prev:
RE: Patch: Move alarm.h and rename alarmString.h Jeff Hill
- Next:
Message values and message texts. Rees, NP (Nick)
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Patch: Move alarm.h and rename alarmString.h Jeff Hill
- Next:
RE: Patch: Move alarm.h and rename alarmString.h Davidsaver, Michael
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|