Hi Babak,
On Friday 24 October 2008 08:56:21 Kalantari Babak wrote:
>
> I have spent some time on writing a new EPICS record type which can
> create new record instances at IOC runtime. At the moment the code is in
> very preliminary level but it works. "It works" means I am able to
> generate instances of almost any record types at IOC runtime. The
> behavior is as the following:
>
> 1. User specifies record type e.g. "ao", "calc", etc. by CA/DB-write to
> a field of "recordGenerator" record
>
> 2. User specifies the channel name by CA/DB-write to a field of
> "recordGenerator" record
>
> - As a result a channel with soft device support (soft channel) with
> corresponding type and name is generated.
Unfortunately there are major problems with doing this in a running IOC: we
don't have locks in all the database structures that need to be modified when
a new record instance is created, which makes this a precarious activity.
The current dbStaticLib design assumes that all record creation happens while
the IOC is running single-threaded before initialization of any scan or
server threads. For example, the pdbbase->ppvd structure which is a hash
table of all the record instances has no locks, so one or more server threads
could be searching for PV names in the hash bucket linked list that your new
record instance gets added to.
Looking at the code in base/src/dbStatic/dbPvdLib.c I can see several ways
that simultaneous calls to dbPvdFind() and dbPvdAdd() in different threads
could cause a segfault, because this code has not been written with that
possibility in mind.
Note that remediation of this by adding locks to the pdbbase->ppvd structure
is not as easy as it might seem because we have to check for deadlocks with
other parts of the system which already have locks in place, and also because
of the effect such locks could have on PV search performance (which IOCs do a
lot of and which dbPvdFind() is currently optimized for).
> One potential usage of this may be to have (soft) waveform records which
> can have changeable size. One way to do this is to copy the content of
> the generated waveform record, then delete existing record and generate
> another one with the new size and fill it in with the data copied from
> the previous waveform.
Deletion of a record from an active database is a *much* harder thing than
adding one, because there are many places that might have a pointer to your
record instance, and you have to find them *all* before you can safely free
the record.
If you want to be able to re-size a waveform record, it would be much better
and easier to modify the record type to support that directly. You'd have to
ensure that the CA server doesn't still have a pointer to the old data
somewhere, but I don't think that would be an insurmountable problem.
> 1. are there any interests (now/in future) in such a record type, in
> another word, is it worth at all to put efforts for such thing?
The ability to create new record instances has been on our to-do list for a
long time, but nobody has tried to work on it recently that I know of. That
says two things: 1: Yes, we'd really like to be able to do it, but 2: it's
not going to be an easy thing to do properly.
> 2. (if yes) what features such record type can/must have?
I would start by concentrating on the underlying ability of dbStaticLib to
create new records while the IOC is running. Putting a record type API on
top of this is the easy part, once the dbStaticLib code can do so safely.
Sorry to burst your balloon...
- Andrew
--
Talk is cheap. Show me the code. -- Linus Torvalds
- Replies:
- Re: recordGenerator record Dirk Zimoch
- References:
- recordGenerator record Kalantari Babak
- Navigate by Date:
- Prev:
Re: recordGenerator record Ned Arnold
- Next:
areaDetector R1-2 released Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: recordGenerator record Ned Arnold
- Next:
Re: recordGenerator record Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|