[Dev] [Cynara] Async admin API proposal

Jacek Bukarewicz j.bukarewicz at samsung.com
Fri Aug 22 12:09:58 GMT 2014


> 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.
I see it more as a workaround of the shortcomings of the current design 
rather than a proper solution. Processing check in place of the call is 
a common use case that library should support without forcing the user 
to do such tricks. This is especially true for dbus daemon which was not 
designed to do asynchronous policy checking and should do such 
processing in place if possible. Calling cynara_async_process in many 
places will force the user to worry about potential callbacks for any 
other requests that have been scheduled previously. This is a potential 
source of bugs. Furthermore, calling cynara_async_process just to get 
answer from the cache seems awkward and not something that this function 
is meant to be used. This will also hurt the performance considering the 
fact that we expect most of requests to be taken from cache.
If you really dislike the fact that cynara_async_check can return answer 
(and invoke callback) immediately then please at least consider adding 
function to poll cache for the given query. That should be fine with 
dbus daemon and other clients that benefit from in-place request processing.

Best regards,

Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
j.bukarewicz at samsung.com

More information about the Dev mailing list