On 01.12.2009, at 12:23, Ludovic Rousseau wrote: >> It is not straightforward to fix the situation in OpenSC(PKCS#11) either, as >> there is no way to know in PKCS#11 if a new thread has been started than to >> keep a list of existing thread id-s and check that one of the id-s maches >> for every pcsc-lite call and manage a list of context handles as well.. > > Is PKCS#11 supposed to support threads? Yes. PKCS#11 supports threaded access to PKCS#11 module as well as (in theory) the module to launch private threads. The major exception that deserves a special comment in the spec is C_WaitForSlotEvent which is exactly the thing that need a blocking SCardGetStatusChange and a SCardCancel (cancel is called when C_Finalize is called). From PKCS#11 v2.20, page 149: """Although the parameters supplied to C_Initialize can in general allow for safe multi- threaded access to a Cryptoki library, C_WaitForSlotEvent is exceptional in that the behavior of Cryptoki is undefined if multiple threads of a single application make simultaneous calls to C_WaitForSlotEvent."""
> >> Although not necessary for SCardGetStatusChange (which only requires a >> context handle), if the requirement would be true for all API calls, then >> every new thread would also have to make the full connection establishment >> to be able to talk to the card? > > I don't think it is a good idea to have two threads talking to the > same card at the same time. But pcsc-lite will/should handle that. *Card access* is serialized, reader/card state access is not. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
