Hello!
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
threads.
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
libcynara:
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.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
