EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: write to a single element of an array field
From: Ben Franksen via Core-talk <core-talk at aps.anl.gov>
To: Ralph Lange <ralph.lange at gmx.de>
Cc: EPICS Core Talk <core-talk at aps.anl.gov>
Date: Mon, 23 Mar 2020 20:04:01 +0100
Am 23.03.20 um 12:10 schrieb Ralph Lange:
> On Sun, 22 Mar 2020 at 11:13, Ben Franksen <
> benjamin.franksen at helmholtz-berlin.de> wrote:
>
>> [...]
>> Here is the the first thing I am seriously stumbling over:
>>
>> static void db_queue_event_log (evSubscrip *pevent, db_field_log *pLog)
>> {
>>     ...
>>     /*
>>      * if we have an event on the queue and both the last
>>      * event on the queue and the current event are emtpy
>>      * (i.e. of type dbfl_type_rec), simply ignore duplicate
>>      * events (saving empty events serves no purpose)
>>      */
>>     if (pevent->npend > 0u &&
>>         (*pevent->pLastLog)->type == dbfl_type_rec &&
>>         pLog->type == dbfl_type_rec) {
>>         db_delete_field_log(pLog);
>>         UNLOCKEVQUE (ev_que);
>>         return;
>>     }
>>     ...
>> }
>>
>> I don't quite get the logic here. What is (the definition of) an empty
>> event? And why does dbfl_type_rec indicate that the event is empty?
>>
>
> Probably a bad term.

No, with your explanation below is makes a lot of sense.

> A dbfl_type_rec update does not contain any data or metadata by itself -
> that's why I called it "empty". It's just a placeholder, signaling to the
> post-queue processing that it should use the current state and data of the
> record, including all metadata and timestamp.
> Putting two consecutive dbfl_type_rec events on the queue would lead to an
> identical update (as all data is taken from the record) being sent twice.
> Not really useful, that's why I decided it to be safe to drop any
> consecutive dbfl_type_rec updates.

I see. In my current version dbfl_type_rec no longer exists, which is
why I have, for the moment, disabled this optimization. I think I could
recover it, at least partly, but I am not sure it is worth the trouble.
This will probably come up again during review.

Cheers
Ben

________________________________

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: write to a single element of an array field Ben Franksen via Core-talk
References:
Re: write to a single element of an array field Ben Franksen via Core-talk
Re: write to a single element of an array field Ben Franksen via Core-talk
Re: write to a single element of an array field Ben Franksen via Core-talk
Re: write to a single element of an array field Ralph Lange via Core-talk
Re: write to a single element of an array field Ben Franksen via Core-talk
Re: write to a single element of an array field Ralph Lange via Core-talk

Navigate by Date:
Prev: Jenkins build is still unstable: epics-base-7.0-win64s-test #147 APS Jenkins via Core-talk
Next: [Bug 1868486] Re: epicsMessageQueue lost messages rivers via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: write to a single element of an array field Ralph Lange via Core-talk
Next: Re: write to a single element of an array field Ben Franksen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 24 Mar 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·