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
Attachment:
pEpkey.asc
Description: application/pgp-keys
- Replies:
- Re: double filters Ben Franksen via Core-talk
- References:
- double filters Ben Franksen via Core-talk
- Re: double filters Johnson, Andrew N. via Core-talk
- Re: double filters Ben Franksen via Core-talk
- Re: double filters Johnson, Andrew N. via Core-talk
- Re: double filters Ralph Lange via Core-talk
- Navigate by Date:
- Prev:
Re: double filters Ben Franksen via Core-talk
- Next:
Re: [Merge] ~bfrk/epics-base:zero-size-array-request into epics-base:7.0 Ben Franksen via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: double filters Ralph Lange via Core-talk
- Next:
Re: double filters Ben Franksen via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|