I have two elements to print. Example item1 and item2
When the command is executed from CLI once, then everything works smoothly. get_next calls twice with -1, then it calls with valid next address
i.e. get_next(-1) -> get_next(-1) -> get_next(item1 address) -> get_object() -> get_next(item2 address) -> get_object
If I execute the CLI command again within a second after the previous command. Then get_next is called twice with -1 then get_next twice again wth valid value
i.e. get_next(-1) -> get_next(-1) -> get_next(item1 address) -> get_next(item2 address) -> get_object()
Summary get_next is called many time even before get_object is called
While I agree that it might be confusing, the data provider should not assume any particular sequence of callbacks. There are many reasons why get_elem or get_object (and others) can be called seemingly out of band, the data provider really needs to be able to respond to any (valid) DP callback.
That means if twice the time I received data with get_next, then its get_next job to handle it properly.
My thought (assumption) was when get_next is finished then get_object should always be called.
My code was like this. I have linked list.
get_next receive first element and reply with next element using confd_data_reply_next_key
get_object receive those and process
since get_next is called twice for non -1 values before get_object, every thing was messed up.
Now I handled in get_next the scenario and not assuming get_object will alway call just after get_next.
Thanks and please let me know my understanding is correct
That is correct. The “no assumptions” approach is the best one for a data provider application.
When using a CLI human-to-machine interface, for example, ConfD will not only have to do data provider calls for the values when the user hits “enter”, but also for tab completes, etc.