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