[Dev] [Cynara] Async admin API proposal

Patrick Ohly patrick.ohly at intel.com
Fri Aug 22 18:05:40 GMT 2014

On Fri, 2014-08-22 at 18:16 +0200, Zofia Abramowska wrote:
> Hi,
> > 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.
> I see your point, but cynara_async_check() can only fail when cynara_async
> structure wasn't initialized or other argument was broken ('invalid parameter')
> and 'with out of memory' in case of some total destruction.

Everything related to this particular cynara_async_check() should be
passed to the callback.

> Should cynara_async_process() errors also be handled in callback (this one will
> fail also when there was some kind of error on socket or reconnecting to cynara
> wasn't possible)?

No, cynara_async_process() should return errors to the caller. It tells
the caller that Cynara in general is dead. This is different from "this
particular check here has failed" which is what an error in the callback

> > 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 handled.
> > 
> > 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 cynara_async_check().
> As I pointed previously, I believe cache is not part of the API
> (but I want to consult it with Lukasz).

The cache is not exposed as an API object. You only offer functionality
which depends on this particular implementation aspect. Note that the
existence of the cache is relevant for application developers and should
be documented, because it offers a guarantee to them that they can call 
cynara_check() without having to worry about round-trip-times to the
server. Otherwise they probably would have to implement their own result

If you don't like a "read from cache" API then think of it as a read or
write on a non-blocking file descriptor instead: either the operation
succeeds, fails or you are told to try again later.

> > This has the disadvantage that you pointed out yourself: the caller has
> > to allocate a place to hold the response before calling
> > cynara_async_check().
> > 
> > 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 matters.
> But in case when cynara_async_check() will return answer, it will also mean that
> it has to be handled with additional code.

Yes, but that code can be simpler. For dbus-daemon, it can be "per
connection" instead of "per check" and doesn't need to store the check

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 mailing list