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. > 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. Bye [1] http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2007-March/002640.html -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
