Hi,
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
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
