Experimental Physics and Industrial Control System

Am 19.03.20 um 19:49 schrieb Ralph Lange via Core-talk:
> A bit of background:
>
> The name db field log was the traditional one. When adding the filters, I
> started to do a refactoring of the code to use more comprehensive names for
> some of the core concepts, and trashed it after a few hours, because I was
> getting commits that changed every line of the code, which I was sure not
> to get past QAndrew.
>
> Originally, there had to be two types of updates (field logs):
> 1. scalar data, where the value and all metadata (incl. timestamp) was in
> the update, and the post-queue processing was copying data from the update.
> 2. array data, where the update contained a pointer to the record, and the
> post-queue processing accessed the record to copy the data out. (into the
> CA buffers)
>
> When adding filters that are able to change the data and metadata of an
> array, there is a need for a third type:
> 3. manipulated array data, where the changed metadata is in the update, and
> the array data is a copy allocated on the heap, i.e. has to be free()d
> after post-queue processing.
>
> The admittedly weird way this extension was merged into the original
> db_field_log structure was intended to keep the changes minimally invasive.

After my second failed attempt at refactoring this mess I can quite well
appreciate the difficulties you encountered.

Judging from your explanation and what I learned from my experiments, I
think the essential difference between dbfl_type_rec and dbfl_type_ref
is the locking: with dbfl_type_ref we know that we are working with a
copy of the (array) data, so there is no need to lock the record,
whereas with dbfl_type_rec the array is still owned by the record. I
wonder if dbfl_type_rec could be replaced with a simple flag in dbfl_ref
that indicates whether the data pointer is owned by the record or by a
freeList. I will experiment with this idea and see how far I get this time.

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?

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

Re: write to a single element of an array field Ralph Lange 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

Navigate by Date:

Prev: Re: write to a single element of an array field Ben Franksen via Core-talk

Next: Error (511,511) Mark 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 Ben Franksen 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