[Dev] [Cynara] Async admin API proposal
patrick.ohly at intel.com
Fri Aug 22 12:01:39 GMT 2014
On Fri, 2014-08-22 at 12:32 +0200, Zofia Abramowska wrote:
> 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
I see where you are going with this. But note that you also expect the
client to handle errors in two places: once after calling
cynara_async_check(), and again in the callback.
If you want to have just one place to handle results, then also ensure
that errors are only reported once. In other words, make the return code
of cynara_async_check() void and invoke the callback with an error code
from inside cynara_async_check() if anything goes wrong.
> - 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.
> - 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?
I can answer this for dbus-daemon: in that case, the result of the check
in the callback would be ignored. The callback would only be used to
retrigger the message processing of the frozen queue. When processing
again, the answer will be in the cache and thus the message can be
The data pointer for the callback would not be allocated specifically
for the cynara_async_check(), so passing a callback and its data pointer
would be cheap.
But I agree, this is a rather special case. How about having a dedicated
method which just consults the cache and returns either allow/deny or
"no information"? If not in the cache, the next step then is to call
> 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.
This has the disadvantage that you pointed out yourself: the caller has
to allocate a place to hold the response before calling
This is not just a runtime overhead issue (which might not matter), it
also means writing more code, at least in the dbus-daemon case, and that
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the Dev