Hello Ludovic, 2012/6/18 Ludovic Rousseau <[email protected]>: > 2012/6/16 Ludovic Rousseau <[email protected]>: >> 2012/6/16 Aleksey Samsonov <[email protected]>: >>> Hello, >> >> Hello, >> >>> I observe deadlock at wait of non SCARD_E_SHARING_VIOLATION with lock >>> of ContextMap (PCSC-Lite-1.8.3 and more early). Problem in >>> SCardBeginTransaction, SCardTransmit(block mode), SCardStatus (block >>> mode), SCardReconnect (block mode). >>> >>> Deadlock case: >>> Thread 1: call SCardBeginTransaction -> SCARD_S_SUCCESS >>> Thread 2: call SCardBeginTransaction (or other from list above) -> >>> lock 'currentContextMap->mMutex' and wait until receive non >>> SCARD_E_SHARING_VIOLATION (until Thread 1 call SCardEndTransaction and >>> return success) >>> Thread 1: call SCardEndTransaction (or other)-> 'wait >>> currentContextMap->mMutex; >> >> Interesting. Do you have a sample code to exhibit the bug? Either in C >> or Python? > > I can reproduce the problem. > > It is not a bug (nor a feature) in pcsc-lite :-) > > As documented at [1]: > " SCardEstablishContext() > Each thread of an application shall use its own SCARDCONTEXT. > SCardCancel() is the only exception to the rule. On Windows the same > SCARDCONTEXT can be shared by different threads of same application. " > Windows may have a different behavior.
Absolutely right, I neglected and I used shared SCARDCONTEXT in different threads of process. Ok, it's a feature of PCSC-Lite. But may be apply patch to improve it (for more compatible with Windows)? Thanks _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
