[Dev] [Cynara] Async admin API proposal

José Bollo 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:
> Hi,


> 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.

Best regards

> 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.
> Cheers,

More information about the Dev mailing list