[Dev] [Cynara] Async admin API proposal

José Bollo jose.bollo at open.eurogiciel.org
Fri Aug 22 12:09:10 GMT 2014

Hi Zofia,

On ven, 2014-08-22 at 12:32 +0200, Zofia Abramowska wrote:
> Hi,
> As Aleksander, Adam and Lukasz are currently on holidays, I'll introduce myself now :).
> I'm Zofia Abramowska and I'm working with guys on cynara. Me and Aleksander are most responsible for version of API #2. I will come back to the design later.
> First of all, sorry for access problems. I have a slight suspicion that using refs/drafts instead of refs/for might be the culprit here. Nevertheless we (me and Marcin) have pushed both changes to refs/for so I hope no one will have problems with accessing them now. Here are the links:
> V1: https://review.tizen.org/gerrit/26245
> V2: https://review.tizen.org/gerrit/26426
> As for the design itself (v2):
> My (and Aleksanders) main concerns about cynara_async_check returning answer immediately are:
> 1. client will be forced to handle two ways of returning answer, which involves:
>    - in case of cynara_async_check() returning cached value through return value, user even after passing response_callback,
>      will have to additionally handle cynara_async_check() return value

that's also my opinion, using the return value is bad.

>    - client will have to be prepared to receive answer in both cynara_async_check() and cynara_async_process().
>      I have no example that comes to my mind now, but for us it seemed that it might come more as a burden to user,
>      than an advantage.

yes problem of reetrancy. but no real problem here IMHO.

>    - because client doesn't know how answer will come, client will have to pass callback and user_data.
>      When cynara_async_check() returns answer through return value, client must provide additional code
>      to support user_data (once in callback and once outside callback). What if user_data includes dynamically
>      allocated data?

no real problem here IMHO. (see below).

> 2. cynara_async_check() will have to perform additional check for cynara disconnection (this is implementation problem, but as cache is only valid when connection to cynara is alive, this must be checked). Moreover both cynara_async_check() and cynara_async_process() will have to perform this check.

this state problem is true but should not be a stopper. the correct way
to handle the case is to detect it in polling and to pass it to
cynara_async_process that will manage the state. See the hangup in

typedef enum {
} cynara_async_status;

> 3. v2 design already gives user a way to receive cached answer immediately - by calling cynara_async_process(). cynara_async_process() does not require event loop, because all operations on I/O are non-blocking. So for fast check, user can pair cynara_async_check() call with cynara_async_process() call.

possible but i dont like this solution.

> That's why Aleksander called this design more straight-forward. User does not have to be concerned about returned value (only checks for errors are required), does not have to handle receiving answer in two places (and maybe even in two different ways - by callback and by returned value) as it will come only from cynara_async_process() only by triggering callback.
> Best regards,
> Zofia Abramowska.

The main topic of your mail is about calling response callback within
cynara_async_check. The main drawbacks I'm seing if staying pending
until further call to cynara_async_process is that the state of the file
descriptor in the main loop will not change. Then returning to the main
loop will not produce poll-able event and cynara_async_process will not
be called.

We naturally fall to the conclusion that you would enforce to call
cynara_async_process after successfully calling cynara_async_check what
is not elegant to my eyes.

IMHO, the callback call within cynara_async_check is better. Just
document it. For handling allocated memory, just state that in case of
success the callback must free and in case of error that is the caller
that proceed.

Best regards

More information about the Dev mailing list