[Dev] [Cynara] Async admin API proposal

José Bollo jose.bollo at open.eurogiciel.org
Mon Aug 25 08:08:56 GMT 2014

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.


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


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

but here again, it is a design choice. having only one flow is also

if I'm correctly understanding your design, if write is blocking, the
cached data are also blocked.

best regards

> Best regards,
> Zofia Abramowska.

More information about the Dev mailing list