[Dev] [Cynara] Async admin API proposal

Marcin Niesluchowski m.niesluchow at samsung.com
Thu Aug 21 18:28:08 GMT 2014


Hi,

> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of José Bollo
> Sent: Thursday, August 21, 2014 5:43 PM
> To: Jacek Bukarewicz
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] [Cynara] Async admin API proposal
> 
> Hello,
> 
> On gio, 2014-08-21 at 17:30 +0200, Jacek Bukarewicz wrote:
> > On 08/21/2014 04:01 PM, Patrick Ohly wrote:
> >
> > Hi,
> >
> 
> (snip)
> 
> > 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.

I pushed another revision of variant #1 (https://review.tizen.org/gerrit/#/c/26245/) (usage example included).

> 
> Best regards
> José
> 
> > 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,
> >
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

Best Regards,
Marcin Niesluchowski




More information about the Dev mailing list