first of all I’d like to apologize for my “lurking” under the surface of the forum, only now and then popping up with a question rather than being a more frequently helpful member of the community. I remain hopeful that one day in the near(ish) future this will change.
In the meantime, I was wondering if somebody could help me understand a little better how threading works in the context of Panda.
Specifically, I would have thought that an application such as a game normally has a small but significant number of threads. For example, I would have thought that one thread handles user-generated events, such as mouse-clicks and key-presses. Another handles I/O to/from the disk or to/from remote resources. I would have also thought that complex Physics or AI simulations, when present, would live in their own threads. And finally, I would have thought that for each of this threads it would have been possible to set (or not) limits, establishing relative priorities (i.e. thread A should have three times the priority of thread B) or actual resource quotas (i.e. thread A should get at most 40% of CPU cycles).
Now, how far off the mark am I in terms of typical architecture? And how much of this is possible through Panda, either because it’s already there or because it can emerge with some scripting?
Panda applications are typically single-threaded. The individual things you’re calling threads are usually written as “tasks”, which conceptually do have a lot in common with threads, but they work differently: with tasks, you have to write your code in bite-sized chunks that don’t take too long to execute (because each task runs in sequence).
Most people prefer the single-threaded model because it is actually much easier to code in than the multi-threaded model. Once you start writing parallel threads of execution, it’s very easy to do something wrong with a race condition or a deadlock, and it’s very hard to debug. However, it is indeed possible to use threads, if you prefer this model. You can even integrate threads with tasks, so that certain tasks are handled by different threads.
Since tasks are typically handled round-robin, where each task executes once in a given frame, and then the whole process repeats for the next frame, scheduling priorities such as you describe is not commonly done. However, this is possible to a certain extent as well, via the TaskChain interface to the TaskManager.
Thank you David for your answer, it is informative and does reply to the issues I mentioned in my initial post. Indeed Task Chains and Task Managers seem to be able to supply pretty much all the functionality I was describing.
Question: would I be correct in saying that there is no way to give to a whole task chain a relative priority in comparison to other task chains? This would mean that to do what I was describing with relative priorities I must still use only the main chain and change the priorities of individual tasks.
Also: what’s the relationship between AsyncTaskManager and TaskManager? It appears that the manual pages refer to the latter as the former does not have a doLater() method, but the reference page on the TaskManager class is only partially documented: is this a class on the way out?
Hmm, I believe this is correct. Relative priorities is a new feature of the task manager, and you may find it is not as robust as some other, more mature features in Panda. Please let us know if it gives you difficulties.
AsyncTaskManager is the fundamental C++ implementation of the task manager. The TaskManager class is a Python-only construct that contains an AsyncTaskManager as self.mgr. The only reason that TaskManager exists as a separate class is for historical purposes, to provide a consistent interface with the original pure-Python TaskManager.