[Dev] libcynara API

Patrick Ohly patrick.ohly at intel.com
Tue May 20 15:41:02 GMT 2014

On Tue, 2014-05-20 at 17:23 +0200, Lukasz Wojciechowski wrote:
> 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:
> > 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.

I prefer that second option. It's what I had in mind.

> 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?


The goal is that one can have two independent modules in the same
process which both get to use cynara without having to somehow become
aware of each other and some global cynara instance.

Again, this is not absolutely required. It's more important to make
service developers aware if it is not possible.

> > 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'm fine with reducing the scope. Just try to avoid design mistakes
which will make it harder to add it later, because I think it will be
needed eventually.

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 mailing list