There seems to be a race condition in pcsctund. Using TL server 3.1.0 (demo system) and the Windows client on my XP laptop, I've managed to hang pcsctund. I've done: * In one console window, executed: while true; do pkcs15-tool -c; done * In another console window: export PCSCTUN_DEBUG=1 tl-run-rdesktop In some cases, pcsctund hangs as soon as Net ID on the WTS starts working. In some other cases, the hang occurs if I disconnect+reconnect the TL client.
Created attachment 366 [details] tlclient.log
The problem has been verified with build 2638, as well as the 3.1.0 client.
Looks like we need to start treating every PC/SC call as potentially blocking, which means a redesign of the pcsctun architecture where a new thread is created for every call.
Since this is not a regression, it's not a 3.1.1 showstopper.
We've been running in to similar problems with rdesktop and it's interaction with pcsc-lite, and just treating every call as potentially blocking might not be enough. The new idea is to give up on the principle of pcsctun being a simple RPC transport. Instead we separate the PC/SC interface presented to the clients from the backend PC/SC calls to the local system. E.g. we might only have a single SCardGetStatusChange() being made to the local system and multiplex this ourselves to all such calls that are waiting from the clients. The point of this is that we can carefully create and use contexts in a way that avoids dead locks. The pcsc-lite architecture blocks the entire context if you have an ongoing blocking call on it. So we would need at least three contexts; one for SCardGetStatusChange(), one for SCardBeginTransaction(), and one for all non-blocking calls. Incoming calls would be multiplexed between these as necessary. See also bug 3404 for rdesktop, as it probably needs the same kind of work and we can probably share code/design.
