[Dev] [Cynara] Async admin API proposal

Zofia Abramowska z.abramowska at samsung.com
Fri Aug 22 16:45:26 GMT 2014


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.

> 
> > @Jose
> > > > 2. cynara_async_check() will have to perform additional check for
> > > cynara disconnection (this is implementation problem, but as cache
> > > is only valid when connection to cynara is alive, this must be
> checked).
> > > Moreover both cynara_async_check() and cynara_async_process() will
> > > have to perform this check.
> > >
> > > this state problem is true but should not be a stopper. the correct
> > > way to handle the case is to detect it in polling and to pass it to
> > > cynara_async_process that will manage the state. See the hangup in
> > > cynara_async_status.
> > >
> > > typedef enum {
> > >     CYNARA_STATUS_FOR_READ,
> > >     CYNARA_STATUS_FOR_WRITE,
> > >     CYNARA_STATUS_FOR_RW,
> > >     CYNARA_STATUS_FOR_HANGUP
> > > } cynara_async_status;
> >
> > How do you expect 100th check with cache hit to be still up-to-date
> if
> > information, that server has disconnected will be processed after in
> cynara_async_process?
> > If after 1st cache hit server has disconnected, all 99 responses are
> invalid.
> > Before every check in cache we must be sure, that this value is still
> valid.
> > We can write in documentation : don't do cynara_async_check if
> > CYNARA_STATUS_FOR_HANGUP is on cynara socket, but I believe it's not
> the point?
> 
> That is a race problem.
> 
> I'm suspecting some misunderstanding. For me, outside cynara, the main
> loop (examples in glibc and ecore) is basically polling file
> descriptors using a function of the poll/select familly. Such function
> detect read/write/hangup/timeout conditions on file descrptors. When
> detected, an appropriated function is called (aka a callback). For the
> file descriptor given by cynara async api, the function is
> cynara_async_process.
> 
> Do you agree?

Yes

> 
> Then, the callback is called on hangup and cynara will state the case
> that a disconnection occurred and invalidate the cache.
> 
> But if there is no return to the main loop, there is no way to check
> the disconnection. Adding a test of the connection before reading the
> cache would introduce a context switch to the kernel avoiding cache
> benefit.
> 

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.

> > > The main topic of your mail is about calling response callback
> > > within cynara_async_check. The main drawbacks I'm seing if staying
> > > pending until further call to cynara_async_process is that the
> state
> > > of the file descriptor in the main loop will not change. Then
> > > returning to the main loop will not produce poll-able event and
> > > cynara_async_process will not be called.
> >
> > 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?
> 
> > 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 ;)

Best regards,
Zofia Abramowska.



More information about the Dev mailing list