Hi, > -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of José Bollo > Sent: Thursday, August 21, 2014 5:43 PM > To: Jacek Bukarewicz > Cc: [email protected] > 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 > [email protected] > https://lists.tizen.org/listinfo/dev Best Regards, Marcin Niesluchowski _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
