[Dev] libcynara API
Zhang, Xu U
xu.u.zhang at intel.com
Mon May 19 11:58:35 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
> Sent: Monday, May 19, 2014 4:30 PM
> 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.
> 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?
[Zhang Xu ] Below is my personal consideration, which maybe not correct.
1. How crosswalk call libcynara?
There are two phase to call libcynara.
a. One is for registering application's permission, which is happed when installing, updating and removing an web application. The permission or policy DB should be maintained by Cynara. The installer will call libcynara to update policy DB.
b. The other is for checking permission when an sensitive web API is called in runtime. For Tizen device APIs, extension process should call SAPI(which call libcynary) to check. But for W3C APIs which run in browser process, browser process may call libcynary directly or send an IPC message to some plugin which will call libcynary.
2. Is the synchronous API good enough?
For the cases I list above, I think synchronous API is enough.
3. Is the thread-safety outlined above going to be relied upon or irrelevant?
I need more time to get a clear answer on this question.
4. Do you need check cancellation?
5. If you need something asynchronous, what drives the main event loop?
I don't think crosswalk need asynchronous API from Cynary.
> 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