Experimental Physics and
Industrial Control System

Hi Ralph, Andrew & whoever else is interested

I am writing this up so you can correct any mistakes in my understanding.

I think I found the missing link (pun, haha) by greping for 'static lset':

> grep 'static lset.*=' *
dbCa.c:static lset dbCa_lset = {
dbConstLink.c:static lset dbConst_lset = {
dbDbLink.c:static lset dbDb_lset = {

That makes sense. These are the three "internal" link types: CONSTANT,
DB, and CA.

(For the following, note that I am working on a version with Dirk's
patches applied.)

Looking at the definitions for dbDb_lset I find that the relevant c
functions are dbGetValue and dbPutValue in dbDbLink.c. I guess what
needs to be done to support filters on put (for DB links) is to change
dbPutValue. Looking at what dbGetValue does I see that two chains of
filters are applied before we finally get the actual value:

        pfl = dbChannelRunPreChain(chan, pfl);
        pfl = dbChannelRunPostChain(chan, pfl);
        status = dbChannelGet(chan, dbrType, pbuffer, NULL, pnRequest, pfl);

This looks a bit mysterious at first: why distinguish Pre and Post
chains when all we do is run them one after the other? Then I found
these comments in the dbChannel.h:

    ELLLIST pre_chain;        /* list of filters to be called
pre-event-queue */
    ELLLIST post_chain;       /* list of filters to be called
post-event-queue */

and indeed the implementation for CA links makes it clear that the pre
chain is run before we call db_post_events, while the post chain is run
when we take things out of the event queue. Again, this makes sense. DB
links aren't queued, so we ignore the distinction and simply run both
chains one after the other.

The next question is what to do about the "pfl" thing i.e. the
db_field_log that gets threaded through the filters. Currently, a
db_field_log is created by one of db_create_event_log or
db_create_read_log. This suggests I need to add some
db_create_write_log, which in turn suggests a new member to enum
dbfl_context i.e.

typedef enum dbfl_context {
    dbfl_context_read = 0,
    dbfl_context_event,
    dbfl_context_write
} dbfl_context;

Searching for code that makes case distinctions depending on the
dbfl_context_*, I see only a few uses in the existing filters:

../../std/filters/decimate.c:    if (pfl->ctx == dbfl_context_read)
../../std/filters/decimate.c-        return pfl;
../../std/filters/sync.c:    if (pfl->ctx == dbfl_context_read)
../../std/filters/sync.c-        return pfl;

I think it makes sense to document this in filters.dbd.pod. Indeed, some
of the filters make sense only in certain contexts. We currently apply
the "Synchronize" and "Decimate" filters only in the event context. I am
not sure if applying "Deadband" and "Sync" make sense in read contexts,
but I won't make any guesses here and keep the code as is, leaving it to
others to review this. Anyway, none of the existing filters except
"Array" seem to make much sense in a write context, so I will update the
existing filters accordingly.

So much for now.

Cheers
Ben