[...] > > I have a hard time figuring out what is going wrong, and especially > > why it is going wrong on windows. > > > > Some discussion with Aaron lead us to a problem that shows > > up with threading: > > > > Create a pool A. > > > > Create a thread > > - create a subpool B of A > > - launch the thread. > > > > Destroy pool A > > - implicitly destroys pool B > > > > Thread exits > > - Destroy pool B > > > > B is being destroyed twice. > > > > To protect against that we either need thread cancellation, and > > register a cleanup with pool B that will cancel the thread if > > the pool is destroyed. Or, we need other means of protection > > against double destruction (refcounting of pool users(threads) > > comes to mind). > > The only way I see to do this is to make destruction of a thread's pool > kill the thread. Of course, that isn't easy to do, because the thread > could be in a non-cancelable state.
Well, if that is the case, we surely shouldn't be freeing the memory from underneath it, now should we? In my mind, killing it, even if non-cancelable, is better than letting it continue with invalid memory. > The only other option is to kill > the cleanup in the thread-exit code if you have already cleared the > pool. I am not sure how easy or hard that would be do to though. The latter won't solve the problem. If the pool is destroyed before the thread completes, the memory in the pool and all its subpools will be invalid. Memory corruption is _very_ likely. There is another way, but that requires a disjoined pool for each thread, combined with a seperate allocator (otherwise we'll have the same problem). > Ryan Sander
