On 01.12.2009, at 13:09, Ludovic Rousseau wrote: > 2009/12/1 Waldemar Dick <[email protected]>: >> following this thread, if I understood corretly, each thread needs its own >> SCARDCONTEXT. >> But to cancel a blocking SCardGetStatusChange(timeout=INFINITE), I have to >> call SCardCancel() from an other thread. >> So, which SCARDCONTEXT handle do I pass as an argument to SCardCancel()? >> Either does SCardCancel() cancel all waiting calls across all established >> contexts or I don't understand how this could work? > > SCardCancel() is the only exception to the rule. > You have to call SCardCancel() with the same context used in > SCardGetStatusChange().
Are you sure you did not want to say that SCardCancel MUST NOT be called with the same context as SCardGetStatusChange was called? Otherwise it would mean that SCardGetSlotEvent/SCardCancel is not really usable for PKCS#11 (or anything). From PKCS#11 spec: """ If C_WaitForSlotEvent is called with the CKF_DONT_BLOCK flag clear in the flags argument, then the call behaves as above, except that it will block. That is, if no slot’s event flag is set at the time of the call, C_WaitForSlotEvent will wait until some slot’s event flag becomes set. If a thread of an application has a C_WaitForSlotEvent call blocking when another thread of that application calls C_Finalize , the C_WaitForSlotEvent call returns with the value CKR_CRYPTOKI_NOT_INITIALIZED. """ On Windows, this can be accomplished by calling SCardCancel() in C_Finalize so that C_WaitForSlotEvent() can return before uninitializing the PKCS#11 module. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
