[Dev] [Cynara] Async admin API proposal
jose.bollo at open.eurogiciel.org
Thu Aug 21 15:43:17 GMT 2014
On gio, 2014-08-21 at 17:30 +0200, Jacek Bukarewicz wrote:
> On 08/21/2014 04:01 PM, Patrick Ohly wrote:
> I see cache-hit case handling as the biggest difference between these
> versions. When the answer is available in the up-to-date cache:
> variant #1
> cynara_async_check will return immediately (also invoking callback).
> variant #2
> cynara_async_check won't return the result immediately even if it's
> in the cache. Check result callback will only be invoked in
> cynara_async_process which typically is called after main loop's
> poll/select (when data is available). User can always call
> cynara_async_process immediately after the cynara_async_check to get the
> results (if available) but that's in my opinion more awkward and less
> efficient. Furthermore one must be prepared to process pending responses
> which for some reason service might not want to handle at that point.
> The upside is that it's probably slightly easier to implement from
> library point of view.
> Personally I strongly prefer solution in variant #1
If the case is well documented, I also prefer it. After calling
cynara_async_check, the thread will probably return to the main loop. So
it is a good optimisation. Maybe a drawback if not reentrant mutexes are
used to protect some data because the callback may be called before the
scoped ressources are released.
> Other differences that are orthogonal to the one above:
> - variant #2 allows check callback to control whether processing of
> incoming messages should be continued or not.
> (we might not want to process all responses in one go to avoid
> visible delays).
> - variant #2 allows to change "connection status callback" function
> and data which I believe is a reasonable thing to expect from the API.
> Both of these could also be applied to variant #1.
More information about the Dev