Recently I have come across a few issues in the way that player handles the cancellation of threads. Basically if you are using any libraries that internally have mutexes, these can be left in an inconsistent state when player shuts down a driver, specifically if the driver is holding any mutexes (via underlying libraries) at the time. My proposed solution is as follows:
1) Change player to run its driver threads with cancellation disabled, and then create explicit cancellation points (ProcessMessage, Wait and a new method TestCancel). These cancellation points will then be the *only* place a driver thread can end.
2) This means that StopThread potentially could take a while to run, so instead of joining the thread detach it.
3) Detaching means we cannot gauruntee the thread is dead when StopThread returns, so move the clean up of thread resources into MainQuit instead of Shutdown
4) Finally when creating a new thread we also have to double check the old thread has died, so we need to wait here, it is possible that with rapid subscribe/unsubscribe calls on a driver that takes a long time between calls to cancellation points some subscribes could time out.
I nearly have a patch ready that implements these changes, it still needs a little more testing, but thought I would get feedback from the community before applying it. This will go into 2.2, while the issue is present in 2.1 the fix changes behaviour sufficiently that it I believe it is best to leave it as it.
Also I believe the issue is severe enough in some cases (due to the difficulty in working around it) that we should look to release 2.2 a little sooner than originally intended, although I would still like to see native win32 builds in with 2.2 if possible...
This email is intended for the addressee only and may contain privileged and/or confidential information