-
-
Notifications
You must be signed in to change notification settings - Fork 113
SCardDisconnect(): avoid unneeded polling stop #235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
If disconnecting last context and the card is powered off (or absent), the powerState does not get changed. In this case there is no need to signal the polling thread.
I am not sure about this change. Stopping the polling thread takes around 0.2 ms. |
Plus all the CPU time the polling thread spends. The issue for me is that this happens always when a final disconnect in the direct mode happens. For various reasons this is often for me: many different code pieces we have do interrogate the reader for its features. This is also happening if using OpenSC or its PKCS#11 module - for all the connected readers. Which for me is almost up to the supported limit. When debugging another issue, I just found this is doing a lot of unnecessary extra work and taking CPU time and causing lot of logging that was misleading me. So I was thinking its better to not do unneeded CPU work, and came up with this. I think this is a win even if it adds a little complexity by means of one extra |
If you think about "all the CPU time the polling thread spends" then you should find it is very important to STOP the polling thread. Instead of that your change will NOT stop the polling thread. What reader and reader driver are you using? |
Seems the commit message was not sufficient, so apologies for the brevity of description. So the situation which PR tries to address is the following scenario:
In this
In context of the CCID driver, both the cancellation of the USB interrupt transfer and then re-arming it are somewhat non-trivial operations as they involve quite a bit of kernel involvement to configure the USB controller accordingly. This suggested PR will avoid all of the above code execution because the event poller is not waken up after disconnecting Hopefully this explains the intent in good enough detail?
Various different reader hardware - all of them on the CCID driver. |
I understand the scenario. What are you doing with the reader so that it is a problem for you? |
It is not needed for correctness. This is purely to reduce CPU cycles used and debug log chatter. Nothing else. |
If disconnecting last context and the card is powered off (or absent), the powerState does not get changed. In this case there is no need to signal the polling thread.