[Dev] [Cynara] Async admin API proposal

José Bollo jose.bollo at open.eurogiciel.org
Fri Aug 22 16:17:55 GMT 2014


On ven, 2014-08-22 at 17:46 +0200, Zofia Abramowska wrote:
> Hi,
> 
> I believe cache was implemented as our optimization, not part of API,
> whence I don't see a place for it to be visible to user of cynara async API.

agreed

> If I am wrong, Lukasz will probably correct me (probably on Monday).
> 
> Now, if we assume, that client does not know about cache, why would
> there be two points in API, which return the response?

?

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

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.

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

?

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

> Still, this is all case of implementation, I just wanted to explain that state of fd
> that we are waiting for is properly managed.
> 
> > 
> > We naturally fall to the conclusion that you would enforce to call
> > cynara_async_process after successfully calling cynara_async_check what
> > is not elegant to my eyes.
> > 
> 
> Yes, because why would you want the answer of asynchronous API outside
> of event loop?

when using event loop, most thing are happening inside it ;P
more seriously, cynara_async_process should be called by the event loop
by design.

Best regards
José

> 
> Best regards,
> Zofia Abramowska. 
> 
> 




More information about the Dev mailing list