I have a custom NativeContainer, that’s being used in two job systems for write access. I am getting the following error:
InvalidOperationException: The previously scheduled job S_ConnectRandomAreas:jConnectRandomAreas writes to the UNKNOWN_OBJECT_TYPE jConnectRandomAreas.JobData.PortalGate_to_Portals. You are trying to schedule a new job S_RegisterAreaPortals:jRegisterAreaPortals, which writes to the same UNKNOWN_OBJECT_TYPE (via jRegisterAreaPortals.JobData.PortalGate_to_Portals). To guarantee safety, you must include S_ConnectRandomAreas:jConnectRandomAreas as a dependency of the newly scheduled job.
I wonder why the jobs don’t manage their dependencies automagically the way they do with components, that need the write access within two or more systems. Do I miss something? How do I manage the system’s dependencies? Can it be done automagically?
You should track dependencies for NativeContainers by yourself, automatic dependency tracking relates on types.
Directly use job handle which using that native container and use it as part of input dependency for the second job which will use that. There is also some “dirty”(not so dirty) hacks (search on the forum) - you can have “fake” type which will be used in systems, which in turn will force dependency system chain dependencies of these systems with jobs using the same container.
Ugh… Either hacky. Is there gonna be auto dependency management
Officially from Unity for NativeContainers? Probably not any time soon. Unity’s advice is to store the JobHandle (or two if you want separate read and write filtering) alongside the container itself. Some people go as far as designing custom modules to handle this, myself included.
Very cool, thank you! any example on such a module?
I thought that the Unity guys took care of it, as they let us mark the containers as ReadOnly
The [ReadOnly] marking is for the safety system, not the dependency managment system. The attribute is part of the job system, which has no automatic dependency management. The Entities package is built on top of the job system, and adds automatic dependency management for component types, but cannot track what you are doing with NativeContainers.
As for an example, I plan on making my work-in-progress game repo public either this weekend or next weekend. It will come with an embedded version of my framework (early 0.2.0) which has such a module.
1 Like
I thought that if they can track RW access for components, they can do the same for NativeContainers. I think I’ll embed JobHandle to my native collections, thank you!