On Wed Aug 3 16:13:55 2022 +0000, Piotr Caban wrote:
I guess that native does some kind of context caching in order to improve efficiency (it may be faster to reuse a context instead of creating new one). The test shows that only some contexts are cached (depending on CPU core number). It means that probably, if context cache is full, the contexts are destroyed on thread exit. It would be useful to know how task collection is behaving in this case. Could you please add such test?
So update: I used `HeapValidate` to check if `Context`s stay valid after thread exit if in use. They don't. It only works because either the Context is not used once the chores are running or the data in the memory stays valid enough for it to not crash. So we don't need to do refcounting. This implementation of `_StructuredTaskCollection` here doesn't use the context anyway once the chores are running, so there should rarely (if ever) be crashes if some program doesn't clean up its task collections.
For the caching: It seems like there are always n/m Contexts cached, with n = the number of logical CPUs (probably `CurrentScheduler::GetNumberOfVirtualProcessors()`) and more interestingly m = the number of schedulers created (default scheduler + any created with `Scheduler_Create`).