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 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 :)
Sylvain.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
