Experimental Physics and
Industrial Control System

Ben Franksen via Core-talk <core-talk at aps.anl.gov> · Mon, 30 Mar 2020 15:21:53 +0200

Am 30.03.20 um 09:49 schrieb Ralph Lange via Core-talk:
> On Mon, 30 Mar 2020 at 06:08, Johnson, Andrew N. via Core-talk
> <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
>
>>     I gets worse though. If we add put/write filters to the picture, then
>>     the feature is no longer "no cost". In fact, supporting it is not
>>     possible without a lot of overhead.
>
>     I agree that put filters are probably completely different to
>     get/monitor filters, and there will probably be only a few put filters.
>
>
> The longer I think about it, the more I think that "put filters" should
> indeed be something completely separate. Maybe the put variant should
> not be called "filter" in the first place, but... "operator"? "manipulator"?
> The data is different. (Mostly no meta data, no timestamp, no "from the
> record" type.)

dbfl_type_rec is now interpreted as "to the record" so that one still
makes sense. Otherwise, yes, traditionally there is no meta data
associated with a put. But I see no principle reason that this must
remain so forever. Indeed, DB links have always supported a limited form
of meta data transfer even for put, via the MS flag. Perhaps it will
turn out that this can be generalized using put filters?

> The operation is different (as seen in the array case).
> There are no pre-queue / post-queue considerations. Many very reasonable
> filters have no equivalent put-thing.

My solution to these issues has been to make registration of a put
filter an additional operation. Just as filter plugins can now choose to
register either pre-queue or post-queue (or both?), they can now /also/
choose to register a put filter.

Up to now I have limited this to a single registration, so there can be
only one put filter per channel. This collided with the use of double
array filters used in the tests, which is one reason why I asked about
that feature.

> Filters and put-things could share configuration and instantiation
> mechanism, maybe in a separate namespace - to e.g. allow "arr" and the
> "[]" to point to the filter and the put-thing.
> Limitations and restrictions could easily apply to one direction only.
> (Chained array filters are ok, chained array put-things are not.)
>
> I think such an approach could simplify the implementation.

Unless I misunderstand the idea, the main drawback I see here is that
the whole plugin mechanism itself needs to replicated for "put
whatever"s. This is quite a lot of uninteresting administrative code
that I would much rather extend with a single function than copy wholesale.

Now, it looks as if Andrew's idea combined with mine (i.e. sparse
arrays) may allow me to support stackable/chainable array put filters
without undue overhead (w.r.t. runtime behavior as well as code
complexity). The prospect of being able to add features like ad-hoc
index subsets is a nice side-effect. We'll see if that works out as
planned...

Cheers
Ben
--
...it is impossible to speak of a depoliticized economy as the liberals
do, or of a separation between economic exploitation and political
oppression as the Marxists articulate. The basic distinction, rather, is
between power and creativity...
             -- Jonathan Nitzan and Shimshon Bichler: Capital as Power

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System