Re: [Merge] ~dirk.zimoch/epics-base:FilterForInfoFields into epics-base:7.0

[Ben Franksen via Core-talk <core-talk at aps.anl.gov>]

Last remark for the moment. What we have with the info items here is that there is no actual owner. The decisions made in dbAccess when it calls dbfl_has_copy is about whether the meta data in the db_field_log is valid. Until now this happened to coincide with the data being owned by the db_field_log. It is clear that for a mutable array value the owner of the data is also the owner of the meta data (size, type, etc). But for immutable data that has no proper owner this is not obvious. So an alternative view would be to say that dbfl_has_copy == dbfl_is_owner stays as is and we add another property dbfl_has_meta_data that explicitly answers that particular question.

You alluded to possible shared ownership using reference counting. Let's see if I understand what you mean. So the actual data is immutable, but may be deallocated when the ref count goes to zero. The producer (normally the record) would create a fresh array but promise not to change the data after "publishing" it i.e. making it available as a field, nor the meta data. Then one could reference that data w/o locking. And since the db_field_log already has room for the meta data, the record (producer) could immediately create immutable reference counted db_field_logs. Was that the idea?
-- 
https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/399414
Your team EPICS Core Developers is requested to review the proposed merge of ~dirk.zimoch/epics-base:FilterForInfoFields into epics-base:7.0.