[Dev] libcynara API

Patrick Ohly patrick.ohly at intel.com
Mon May 19 21:21:23 GMT 2014

On Mon, 2014-05-19 at 19:45 +0000, Schaufler, Casey wrote:
> > -----Original Message-----
> > From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> > Sent: Monday, May 19, 2014 12:26 PM
> > To: Schaufler, Casey
> > Cc: Lukasz Wojciechowski; dev at lists.tizen.org
> > Subject: Re: [Dev] libcynara API
> > 
> > On Mon, 2014-05-19 at 19:18 +0000, Schaufler, Casey wrote:
> > > > I can't spawn a thread either to handle the call, because libcynara
> > > > is not documented to be thread-safe. I don't want to make
> > > > assumptions about what I may or may not do with threads.
> > >
> > > You can count on libcynara being thread safe.
> > 
> > What happens when one thread calls cynara_finish() while another is in
> > cynara_check()?
> Do you plan to do that, or is this another hypothetical exercise?

I plan to clean up properly when the process shuts down. This includes
calling cynara_finish() ("should be called once before exiting
service"). Once I do that after having introduced threading, I need to
know what happens when there is a parallel cynara_check(), or whether I
am expected to avoid this situation.

So no, this is a very real exercise in figuring out how to use Cynara

> > I can imagine multiple outcomes, some less pleasant than others.
> > Whatever the outcome is, please document it.
> Patrick, you are not going to get the level of documentation you
> keep demanding. Read what's there. Look at the code.

Okay, I did (commit f2559afa, May 8th). There are no mutex calls at the
moment. cynara_finish() and cynara_check() are not thread-safe.
cynara_check() just calls security_server_app_has_privilege(), which is
going to change. So what does that tell me regarding thread-safety of
the final Cynara?

Nothing, therefore my questions.

If I had relied on the code instead of asking, I would have come to the
wrong conclusion that Cynara is not thread-safe.

My point is, looking at code that is under development is pointless (no
pun intended). There is an API proposal on the table how libcynara is
meant to behave. The Cynara developers were so kind to invite comments
early because they know that other developers will have to use this API.
Now we have the chance to discuss the API while work on the
implementation continues.

That aside, even if the code was stable, are developers really supposed
to look into the implementation to figure out how an API works? How can
they be sure that they don't start to depend on behavior which isn't
guaranteed to be present in the next release?

In case it isn't obvious, I don't buy the "read the code" argument when
it comes to APIs. An API is the binding contract between library
implementer and library user. Using anything not documented there leads
to the gray area of undefined behavior. The less we go there the better.

>  Ask specific
> questions that are relevant to actual uses.

I did that.

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