On Feb 16, 2008 12:28 AM, Eric Walter <[EMAIL PROTECTED]> wrote:
> Hi,
Hello,
> it seems SCardReleaseContext will just return SCARD_E_NO_SERVICE and skip
> removing the local context if the daemon is not running. From
> pcsc-lite-1.4.99-svn-2812:
>
>
>
> LONG SCardReleaseContext(SCARDCONTEXT hContext)
> {...
>
> if (SCardCheckDaemonAvailability() != SCARD_S_SUCCESS)
> return SCARD_E_NO_SERVICE;...
>
> SCardLockThread();
> SCardRemoveContext(hContext);
> SCardUnlockThread();
>
>
> PROFILE_END
>
>
> return scReleaseStruct.rv;
> }
>
> Now, an application might at a later time try to allocate a new context
> successfully if the daemon ist alive again. If this happens a couple of
> times, it seems like the slots for contexts will be exhausted and
> SCardEstablishContext() will then fail. So wouldn't it seem to be the proper
> thing to do the SCardRemoveContext() regardless of daemon availability?
That would be a good idea.
We can generalize this and call SCardRemoveContext() every time the
daemon is not present anymore (before returning SCARD_E_NO_SERVICE) to
free the allocated context.
So future PC/SC call would get SCARD_E_INVALID_HANDLE.
Does any body knows the Windows PC/SC behavior in such a situation?
Do you have a particular setup so you (often) get the SCARD_E_NO_SERVICE error?
> Older PCSC-Lite versions appear to have been meant to behave like I
> outlined. Though in the case of winscard_clnt.c in Mac OS X 10.4.x it didn't
> work because local rv was not initialized to zero:
You should report Mac OS X bugs to Apple (http://bugreport.apple.com/)
The SCardReleaseContext() function in Tiger (10.4) is bogus (not just
when pcscd is no more there). You can't do more than 16
SCardEstablishContext()/SCardReleaseContext() if you do not call
SCardConnect in between.
This bug is solved in Leopard (10.5).
Bye
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
