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