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
<2020>
2021
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
<2020>
2021
2022
2023
2024
|