[Dev] libcynara API
casey.schaufler at intel.com
Mon May 19 16:19:34 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
> Sent: Monday, May 19, 2014 1:30 AM
> To: Lukasz Wojciechowski
> Cc: dev at lists.tizen.org
> Subject: [Dev] libcynara API
> 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.
Please supply an example. A real one. From Tizen. Let's not go
off into yet another hypothetical discussion about how things
ought to work, or what problems we might encounter. We have
more than enough work to do without building interfaces for
cases we are not actually using.
> 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-
> 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
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev