[Dev] libcynara API
patrick.ohly at intel.com
Tue May 20 14:14:48 GMT 2014
On Tue, 2014-05-20 at 15:44 +0200, Lukasz Wojciechowski wrote:
> 3) parallel checks run from multi threads and cancellation of checks are
> needed by some but not all usages to cynara check.[Patrick Ohly]. I
> think we should provide thread-safe API that meets described
> requirements described by Patrick (allowing cancellation and concurrent
> checks launching).
Just to be sure, this includes all points that I proposed in my initial
email regarding thread safety? Casey only said that one can assume that
libcynara will be thread-safe, but didn't go into details of what that
The points where:
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.
Regarding the "needed": it's not absolutely required that you implement
this right away. I brought it up now because it might be easier to take
these aspects into account while designing Cynara vs. adding it later.
Until you add thread safety as outlined above, permission checks (or
more generally, all calls to libcynara) could be serialized by the
caller. This has the downside that a long-running permission check for
client A of a service blocks permission checks for client B of that same
service, but that's probably acceptable in the first step. The service
also needs to be aware that it cannot cancel a running check during
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