2009/10/1 s.ferey <[email protected]>: > Ludovic Rousseau a écrit : >> >> 2009/10/1 Paul Klissner <[email protected]>: >>> >>> Hi, >> >> Hello Paul, >> >>> During some testing of the Sun version of PCSClite we noticed >>> some SCARD_E_SHARING_VIOLATION errors in SCardReconnect(). >>> >>> A co-worker pointed out that winscard_clnt.c was patched (2475) in the >>> open source code to make SCardReconnect() loop (re-try) when >>> SCARD_E_SHARING_VIOLATION occurs, thus masking the error. >> >> The idea is not to mask the error but to be Windows compatible (if I >> remember correctly) >> I made the change in revision 2475 [1] but have not documented _why_ >> the change. And I don't remember who asked for the change. I will have >> to look in my email archives. > > AFAI understand it, this is NOT a Windows specific behavior. > SCard[Re]Connect can return SCARD_E_SHARING_VIOLATION if an exclusive > connection is alive or if excl. conn. is requested while another conn. > exist. this is not OS dependant. > > a loop/retry strategy is IMHO not the good answer since the low level method > has not idea of the existing conn., OOH the calling appl. may choose to deal > with shared conn. if exclusive one can't be obtained.
That makes sense. I will revert the patch soon, unless someone objects. I searched my mail archives and could not find any reference to this 2475 patch. >>> That looks like a workaround for something. But does it mask the >>> error a bit *too* earnestly? >>> >>> I'm wondering: Why is there not some sort of re-try maximum >>> in that loop to keep it from looping infinitely without letting the >>> application know there's an issue, and why isn't there some sort >>> of time delay to throttle down the rate to keep it from spinning too >>> fast? >>> >>> Also, I notice there is no such workaround in SCardTransmit(). >>> I assume maybe there's a good reason to handle it differently in >>> the two API calls, but I just want to find out if it was a conscious >>> choice to add it to one and not the other, or not. >> >> If you do not want to wait in SCardReconnect() you can use >> SCardDisconnect()/SCardConnect() insted. SCardConnect() will not block >> and return SCARD_E_SHARING_VIOLATION immediately. >> >> Do you know the behavior of SCardReconnect() under Windows? That >> should be the reference for pcsc-lite. > > Do you mean we're missing an important Windows specific detail? > Thanks to summarize it, these exchanges will be more efficient :) I just say the reference implementation is winscard in Windows. If pcsc-lite is different then pcsc-lite must be corrected (unless it is a bug on the Windows side) Regards, -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
