hi all, On ven, 2014-08-22 at 18:45 +0200, Zofia Abramowska wrote: > Hi, > > > > > > > Now, if we assume, that client does not know about cache, why would > > > there be two points in API, which return the response? > > > > ? > > Two points meaning two API functions would return answer, when one should > be for creating request and one for receiving responses.
ok. nothing about that, do the good job. (snip) > I don't see why there would be no return to the main loop? As long as > client wants to check privileges using cynara connection should be maintained > so at some point cynara_async_process() will be called. > Still if there is no return to main loop (for some reason I don't see) and > cynara_async_process > will be never called do we want to let client run with cache filled with > wrong permissions? > Tell me, do we, as cynara client, want to be sure we are giving proper > permissions? > Because if yes, then we don't want to miss the moment of cache invalidation. > We won't be able to remove race condition between syscall check for > disconnection and > disconnection itself, but we can minimize it. yes minimize it. but it remains a race condition. the problem here is to not loose time doing non-essential syscalls. (snip) > > > I'm not sure what you mean here. cynara_async_check will always > > > assure, that we are waiting for writeable on socket (as it would be > > > with API #1, when there is no cache hit - we still need to send > > request to cynara). > > > > ? > > What is not clear for you? finally clear: cynara_async_process will write then cynara_async_check will always require the writeability. > > > > > I want to make one thing clear - every operation on socket is made > > > inside cynara_async_process, as both write and read can return EAGAIN > > > and we don't want to handle that anywhere (meaning - we want to > > return > > > control to user without indicating any error like > > > CYNARA_API_TRY_AGAIN). When write returns EAGAIN we return control to > > user and we are still waiting for writable on socket. > > > When we write everything we wanted, we call cynara_status_callback to > > > wait only for readable (waiting for responses or disconnection). > > > > That is design choice. Writing (try to) the not blocking socket inside > > cynara_async_check is also possible. > > We want most things to happen inside event loop ;) that will almost be always the case ;D there is still argument to make direct calls of the callback inside cynara_async_check: it would be faster and the memory consumption may be less. but here again, it is a design choice. having only one flow is also good. if I'm correctly understanding your design, if write is blocking, the cached data are also blocked. best regards josé > > Best regards, > Zofia Abramowska. > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
