[Dev] [Cynara] Async admin API proposal

Patrick Ohly patrick.ohly at intel.com
Mon Aug 25 10:52:07 GMT 2014


On Mon, 2014-08-25 at 12:04 +0200, Jacek Bukarewicz wrote:
> Hi,
> 
> On 08/25/2014 11:30 AM, Aleksander Zdyb wrote:
> > On 25.08.2014 11:04, Patrick Ohly wrote:
> >> Having error handling for cynara_async_check() only in one place would
> >> make that code simpler.
> >>
> >> Assuming that we don't need a return code from cynara_async_check() to
> >> indicate an immediate granted/denied result, do you agree that
> >> cynara_async_check() can return void and any errors will be passed to
> >> the callback?
> >>
> >
> > Patrick,
> >
> > yes we can do that. Please just keep in mind, that we just wanted
> > to divide errors:
> > * "with function call" (for example invalid params,
> > especially cynara_async *p_cynara, NULL callback, etc.) -- returned
> > by function and errors
> > * "in processing" (especially returned by Cynara server via socket)
> > -- returned in callback.
> >
> > However we do not insist on that solution and we're good with
> > void version proposed by you.
> >
> 
> I think that cynara_async_check not returning error code would make life 
> harder for clients that actually need response in place of the call 
> (that is the case for dbus-daemon I guess ?).

My question above was about the case where we either force dbus-daemon
to get the result through the callback (clearly not optimal) or have a
separate cynara_check_nonblocking() (I just made up the name, more on it
below).

The sequence in dbus-daemon then would be:

- cynara_check_nonblocking()
- error and result handling
- if no answer available, suspend connection
- cynara_async_check()
- no error checking needed here
- return to main event processing
- when check completed, try connection again

> To sum up, I don't see any practical benefits of this function returning 
> void. Returning such value doesn't force the client to handle it fully 
> in the place of the call but just gives such possibility which I see as 
> advantage rather than a drawback.

So you are saying that the error should get returned twice, once from
cynara_async_check() and again to the callback? I find that confusing.
In the callback it would be hard to tell whether an error is new or has
already been handled.

> Additionally if it returned response or error that would be consistent 
> with existing synchronous API.

The synchronous API is a different case. For consistency, look at other
asynchronous APIs. I gave glib as example in the patch review. Async
methods return void there.

Regarding cynara_check_nonblocking(), this could be rolled into
cynara_check() by adding an integer flags parameter. Having such a
parameter is a good thing, regardless whether it is already needed (see
https://lwn.net/Articles/585415/ - that's about syscalls; adding a flag
parameter to a userspace library is perhaps easier, but still not nice).

Then we could have
  cynara_check(..., CYNARA_NONBLOCK)
and a CYNARA_EAGAIN error code for the case when the check cannot be
done without blocking.

Obviously this depends on implementing the asynchronous and synchronous
API in the same library, which IMHO should be the goal.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list