[Dev] libcynara API

Patrick Ohly patrick.ohly at intel.com
Mon May 19 08:29:56 GMT 2014


Lukasz asked me whether I had any specific proposal for an asynchronous
version of the Cynara service API. Remember, at the moment libCynara
only promises to provide three synchronous functions (cynara_initialize,
cynara_check, cynara_finish).

Nothing is said about thread-safety, so one has to play it safe and only
call these methods from a single thread, ideally always the same one.

I strongly suspect that using the API as defined at the moment will be
hard, in particular in processes which have to stay responsive while a
Cynara call is running. Note that the shared Crosswalk process most like
falls into this category (confirmation needed!), so this issue is not
limited to some esoteric system service that no-one cares about.

As a first step, let's extend the existing API such that it can be used
more predictably in a multithreaded service. Here are the promises that
need to be added to the API spec:
     1. cynara_initialize() will complete "quickly" enough such that the
        delay caused by calling it will not be noticeable to the user.
     2. cynara_initialize() can be called multiple times in the same
        process, either sequentially or concurrently in different
     3. cynara_finish() must be called once for each
        cynara_initialize(). Again it is allowed to call cynara_finish()
        concurrently in different threads.
     4. cynara_check() can be called by different threads concurrently.
        If a cynara_check() call is running when cynara_finish() gets
        called, then cynara_check() will return with an ABORTED status.
     5. cynara_finish() will complete "quickly" and thus is safe to call
        as part of the cleanup code of a service.

Rational for allowing multiple cynara_initialize() calls: if you have
two entirely independent modules using cynara, then there is no
intermediate layer which could mediate access to cynara.

The "quickly" part is obviously fuzzy. It's easier to determine which is
not quick than what is quick enough: for example, waiting for user input
is a no-no.

One problem remains: if one thread calls cynara_check() and another
thread determines that the check is no longer needed, that second thread
cannot force cynara_check() to return. cynara_finish() goes to far.

So that leads to another API where specific cynara_check() calls can be
canceled. Instead of shoe-horning that into the synchronous API, let me
suggest that we make that part of an asynchronous API.

Before we proceed, let's gather more information about future use of

     1. Crosswalk: can someone from the Crosswalk team please describe
        how they will call libcynara? Is the synchronous API good
        enough? Is the thread-safety outlined above going to be relied
        upon or irrelevant? Do you need check cancellation? If you need
        something asynchronous, what drives the main event loop?
     2. For EDS and SyncEvolution and possibly other services,
        integration into a glib event loop will be needed. There are
        error paths where running checks need to be canceled.
     3. Optional: dbus-daemon. Does not use glib. Instead it has its own
        fd set abstraction dbus-socket-set.c with epoll() as the main
        underlying wait mechanism on Linux. Further investigation needed
        if we want to make this work.

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