[Dev] libcynara API

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Tue May 20 15:23:16 GMT 2014

W dniu 2014-05-20 17:07, Patrick Ohly pisze:
> On Tue, 2014-05-20 at 16:32 +0200, Lukasz Wojciechowski wrote:
>> W dniu 2014-05-20 16:14, Patrick Ohly pisze:
>>> 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
>>> really means.
>>> 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
>>>           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.
>> I agree to all, except 4b) which I don't understand : " If a
>> cynara_check() call is running when cynara_finish() gets called, then
>> cynara_check() will return with an ABORTED status. "
>> Do You want cynara_finish to abort all cynara_checks run from all
>> threads or just one? If one, which one?
> Suppose you allow concurrent calls to cynara_finish() and cynara_check()
> and one thread is inside cynara_check() for the cynara instance that
> another thread is trying to free with cynara_finish().
> What should happen in your opinion?
I have two propositions in thata matter:
1) all cynara_checks in all threads are aborted.
2) every cynara initialize return some kind of object that is later used 
to run cynara_check. When calling cynara_finish with this object as 
argument - only cynara_checks related to that object are aborted and 
object becomes invalid.
> Above is my proposal, with the goal in mind that cynara_finish() should
> better be called when the process shuts down even when there are active
> checks. It's not absolutely required. Process shutdown could also take
> shortcuts and avoid freeing some resources when it cannot do that.
You mentioned that number of cynara_finish calls should be equal to 
cynara_initialize. If your process called cyanar_initialize n-times from 
different thread, You want to run cynara_finish n-times during process 
clean-up. Am I right?
>>>        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.
>> By "needed" I understand that there is a software for Tizen that wants
>> to use cynara but it cannot in current form of API, so we need to
>> enhance it.
> Concurrent cynara_check() calls are needed in that sense only if one
> wants to allow concurrent privilege checks. I don't have a strong
> opinion about whether that is needed for Tizen.
If it is not needed, maybe we shouldn't work on that for now.
> I could use a non-thread-safe libcynara when taking extra precautions in
> the code calling it. It's more a matter of properly documenting what
> works and what doesn't than it is to support advanced functionality.
best wishes

More information about the Dev mailing list