Code review comment for lp:~epics-core/epics-base/link-support-2

We will have to mark the dbLink.h and possibly dbJLink.h APIs as incomplete for the 3.16.1 release then, because they will have to change to add the locking support. I would also expect that change to move the code for handling DB_LINKs from dbLock.c into dbDbLink.c.

> all involved records be known when dbParseLink() returns.
...
> I'd like to see more validation in dbParseLink()

There is syntax checking of the JSON that happens at dbLoadRecords() time, but no semantic checks of the content then. Currently dbInitLink() and hence dbJInitLink() are called from doResolveLinks() in iocInit.c which is part of initDatabase(), whereas dbParseLink() is run from prepareLinks() which happens earlier, before any record initialization has happened.

I don't see any problems with doing the JSON parsing earlier though, so I will work to split dbJLinkInit() into two parts: One called from dbParseLink() for parsing the JSON into a jlink pointer stored in the dbLinkInfo object, and a second one called from dbInitLink() that assigns the jlink object to its specific link field and sets plink->lset.

> Can you describe the difference between dbPutLink() and dbPutLinkAsync()?

dbPutLinkAsync() is used by all of the dev*oSoftCallback.c device support, i.e. Async Soft Channel support for output record types. This isn't new functionality, it's why CA has ca_put_complete(), to wait until all record processing at the far end has finished. If you come up with a better name for this routine let me know.

On completion the link's implementation must call the routine dbLinkAsyncComplete(plink) which locks the record and calls the record's process() routine. Previously for CA links the device supports all called
    dbCaPutLinkCallback(plink, DBR_xx, &prec->oval, 1, dbCaCallbackProcess, plink)
but since they all specified the same callback routine and context parameter I thought we might as well take those out of the argument list.

I was wondering if we could make the completion more useful by adding another RSET routine which (if set) would be called instead of process(), passing it a pointer to the link that just completed; the idea being to simplify record types like motor and table that remain active for long periods and want completion notifications. However I need to consider how the callback would work for embedded links, so I might need to reinstate those callback parameters).