c4d.threading – a module for threading

To get an overview of the class members, check out the diagram.

This module constructs higher-level threading interfaces on top of the lower-level thread module.

Note

Please note that all members of this module are just implemented with the sign ‘experimental’ which means that there is no garantuee everything works fine.

Class

• Thread

Threading information

Programming a lower level thread is not as easy for the most people so this module will help you to minimize the effort to run or handle your code in another Thread. Python 2.6 is shipped with a standard module which already supports a Thread class, but CINEMA 4D and Python use different implementations so the synchronisation might fail and crash. Because of this, you should always use this module instead of the Python standard module, since all functions in this module are wrapped from the CINEMA 4D Api and therefore stable.

The Thread class you see above should work without crashs provided you follow the recommandations and the limits written on this page. Like all the other extensions, the threading module is written in C++ and designed to catch a lot of bugs which might occur a deadlock. Also some reference bugs are catched so CINEMA 4D is still stable, even you wrote buggy Python code.

Because its very hard to find bugs in a multithreaded environment you should report each crash.

All parts of the execution/drawing pipeline of CINEMA 4D is threaded. This means that all calls to TagData.Draw(), TagData.Execute(), ObjectData.GetVirtualObjects(), ObjectData.Draw() etc. are made from a thread. In this method you must not modify the scene in any case (inserting, change order, ...). As an exception, modifications are allowed that change the object’s parameters like the position.

ObjectData.GetVirtualObjects() is of course allowed to do ANY modifications that do not modify the scene: as the object returned is not in the scene at that time it may be changed/created in any way necessary.

Internal information

If you are familiar with Multithreads the following information might help you to fix bugs in your code or align your modules to get the best stability. Py4D uses the concept of an interpreter lock. Just the thread and Python operation which holds the interpreter lock is allowed to execute 100 bytecode instructions. After these operations the interpreter lock is temporarily released and the next Thread holds the reference (only when the thread is signed up for the interpreter lock). This is a circular lock concept.

This lock works fine but has a disadvantage - Multithreading with different processors would be senseless. Imagine - just the thread which holds the global interpreter lock is allowed to execute 100 Bytes of instructions, all the other have to wait. When this module would support to execute the code from another processor the first processor has to wait until the other one is finished.

Note

In a few cases it might be useful to change the value of 100 bytecode instructions. Check out sys.setcheckinterval

Forbidden functions

For all threaded functions it’s forbidden to:

1. Add an Event.
2. Make any changes to materials.
3. Change the structure of objects attached to the scene.
4. Change parameters of elements attached to the scene (allowed, but not recommended except for tags).
5. Call a Draw function.
6. Perform any GUI functionality (e.g. displaying messages, opening dialogs etc.).
7. During drawing to do any file operations. (During execution t’s allowed.)
8. Create undos.

Scene modifications

Before making modifications in the active scene, for example from a dialog, you always need to call stop_all_threads. You have to do this even if you yourself are in the main thread,since there could be other threads that read from the scene.