Re: EPICS 7.0.2.1 release preparation

[Dirk Zimoch via Core-talk <core-talk@aps.anl.gov>]

On 07.05.19 19:58, Johnson, Andrew N. wrote:
> > > The first one dbLinkIsDefined() tells you whether the field is attached
> > > to a link support at all.
> >
> > But to use them, I have to cast the field like ((DBLINK 
> > *)dbEntry.pfield) before I even know if it is a link at all, because 
> > the functions work on links, not on generic db fields. Can that be safe?
> You should only pass those link routines a pointer to a link field. 
> However the IOC has a list of the link fields in each record type and 
> two routines dbGetNLinks() and dbGetLinkField() in dbStaticLib to get to 
> those fields. If you look at the code for dbReportDeviceConfig() you'll 
> see them being used.

Oh yes, that really helps. I had not noticed dbGetLinkField() before.

> Your current code iterates through every field (up to 269 depending on 
> the record type) of every record instance in the IOC database, 

Right. Not any more thanks to dbGetLinkField().

> and for every link field (DB or CA) it performs a record-name lookup on the PV 
> name in that link (which requires calculating a hash of the name and 
> checking the names in that hash bucket, which may have several records 
> in it so does several string comparisons, most of which are going to fail).

I don't think so. I do epicsStrGlobMatch(), but that does not look up 
records by name or calculate hashes. Still it fails on most records, of 
course. Like dbgrep does. I don't think that I can avoid the glob match, 
even when iterating target records instead of links, but the number of 
matches performed may be smaller. In particular when I only check 
records that are known to have links pointing to them.

> If you use the new BKLNK field in the record you will still have to look 
> through every record instance, but for each record you immediately know 
> how many DB links point back to this record, which in most cases will be 
> a small number or 0.

Yes, that may shortcut things. Unfortunately it does not give me the 
name of the link field. But searching the record were the link came from 
is not too difficult.

> Now this doesn't give you CA links
Which is a pity. I understand why, as it was implemented to handle lock 
sets. But for my use case it would be really helpful to get all types of 
links.

> and the order 
> in which you will get results is going to be different because your 
> primary scan is now by link target instead of by link source,
No problem, I do not care much about the order.

> but the 
> work required to scan the list will be significantly reduced. Look at 
> dbLock.c for how Michael uses bklnk and dbDbLink.c for how it gets 
> populated.
>
> HTH,
>
> - Andrew

Thank you for your input. That was very helpful.

Can you tell me what link type PN_LINK is? It seems to be used only in 
dev*SoftCallback.c but I found no documentation about it.

Dirk