Use case: I want to have a normal C# thread or compute shader dispatch being part of job system in terms of dependency. So when I create a managed C# thread - I want to also create a job that will only track whether that thread is done or compute shader pass is finished. But at the same time - don't lock actual worker thread.
If I wanted to do that right now, I'd have to just schedule a job that polls IsDone on my thread and it'll block whole worker thread.
#"Fake" jobs to manage dependencies
burnt lake
dark knot
We internally have this mechanism -- it's how the AsyncReadManager can provide a JobHandle for work that will end up completed by an IO layer which could be device specific. We however haven't exposed it to C# since if you don't complete that manual fence, you will deadlock
I don't think it's an unreasonable request to have though and it might be worth us to add some safety to signal when you have forgotten to complete these fences, we could make it obvious how to fix your hanging of the editor/player. The main concern is that it goes against the C# Job System ethos of making it impossible for users to deadlock, so I can't promise anything since it's an important quality we don't want to lose
burnt lake
I don't think it's an unreasonable request to have though and it might be worth ...
you have some sort of mechanism against while(true){} within jobs?
dark knot
Not one that is exposed. Internally we allow you to make a JobHandle that isn't attached to a job. It acts as a barrier for other jobs which can be manually siganlled by calling .Complete() on the barrier job
However as a result, if you don't call .Complete on the barrier job, anything waiting on the barrier as a dependency will never start and you could hang if you then wait on the job that depends on the barrier
burnt lake
I guess one way to solve this: force specify maximum frames such job can live
dark knot
Possibly. It really depends on what the use case will be. For instance, we do internally use this for IO, so this could reasonably take a long time and all is well since we internally ensure that we always .Complete such barrier jobs.
So I totally get the need to want to have some job inappropriate work depend on / be depended on by the job system
I think we can instead add some more structure to enabling a path for this that is safe without such a general barrier mechanism, but I haven't fully written that off either
burnt lake
My use case: I want to schedule managed threads within entities updates.
It can only be done within managed context and since you can't pass managed data to jobs - I'll create my own task with worker threads. But I want to keep all dependencies within other jobs
Alternative solution is ofc - ability to pass managed data to scheduled jobs
dark knot
I want to schedule managed threads within entities updates.
I would overall recommend trying to frame work into jobs to avoid contending with worker threads.
Technically, worker threads can read managed data they just can't be inside the job data, so if you have another means to fetch the managed data from within your job that is allowed
burnt lake
but that doesn't solve the need in compute shaders. Which I'd want to schedule between normal system updates as well
dark knot
But another approach to do explicitly what you're asking is to launch managed jobs and use a semaphore to signal the threads from jobs. This isn't particularly efficient though and would overall be better if the work being done on the managed threads is inside the job.
You won't be able to pass a Semaphore in as JobData but you can do a slew of workarounds such as accessing a static, or pinning the semaphore and passing in the IntPtr and resolving the semaphore in the job from the ptr
burnt lake
But another approach to do explicitly what you're asking is to launch managed jo...
yeah, all that is very inconvinient
but I guess with ThreadStatic attribute it can potentially be simplified a bit
burnt lake
> I want to schedule managed threads within entities updates.
I would overall re...
also, this isn't really a concern here, because the whole reason I want to tie my tasks to job system is because I want worker threads to stall until all dependencies on my managed task are finished.