(It should be noted that if you use the most recent build of CMake to generate solutions files for VS2010 then the most recent version of Bullet compiles and works fine; don't try and 'upgrade' the existing VS2005 files as it all goes a bit wrong
)At the very basic level I wanted to see how easy it would be to integrate their task based system into Bullet's existing threading support, and for the most part it looks like it shouldn't be a problem, following the pattern which has been layed down by the existing Win32 thread support.
However, there is one area where they might be a problem; tracking busy threads/tasks.
Having traced through the code I arrived down in the SpuCollisionTaskProcess class and specifically issueTask2 which seems todo the grunt work of throwing tasks out to the threads/spus. (Ln117, SpuCollisionTaskProcess.cpp)
It seems that both this, and the calling function, try to keep track of how many tasks are currently active in order to pass work around to them and do so via class variables; this could be a hinderance to integrating CR support.
The reason being with the CR you can queue tasks up and let the underlaying scheduler dispatch tasks as resouces appear; technically this means there is no concept of maximum outstanding tasks as all tasks will be queued and executed at some point in time.
To this end, I'm proposing that the responibility of tracking active tasks, reporting that there are no free tasks and handling 'wait' conditions to ensure that all tasks have completed before moving on be moved into the ThreadSupportInterface; this would allow CR (and most likely Intel's Threaded Building Blocks) to effective 'fake' task resouces while allowing SPU and static thread based tasks to still maintain a maxium pool of tasks they can deal with at any given time.
While I could set about and do this myself I thought I would throw this out there to see if those who have more experiance with the library could offer any reasoning as to why this change would be a bad idea.
My reasoning for wanting it is simple; while static threads are a decent solution currently dynamic task based is the way forward. While Bullet could maintain its own internal thread pool I feel it would be much more natural for it to allow cooperation with existing thread pools so that application developers can better dispatch resouces as they see fit and generally allow the processing to play nicer with the rest of the system.
Any feedback would be appricated, thanks
