Quick question to clarify Filament API thread-safety requirements

[emezeske]

In various code comments / forum posts, I see folks talking about the requirement to call into the Filament API from only a single thread.

However, from looking at the code, and also this comment from pixelflinger, it appears that there is not truly any requirement for all Filament API calls to original from the same client thread, but rather it's just that the Filament API is not thread-safe. So calling into it from only a single thread is the easiest way to guarantee safety, and a good recommendation, but it is actually perfectly safe to call into Filament from multiple threads if they are (externally) synchronized appropriately, such that the Filament API is never accessed concurrently.

So what really is the contract for Filament? Is it:

1. The Filament API is not thread-safe, so we recommend calling into it from only a single thread, but if you know what you're doing multiple threads are safe as long as they are guaranteed not to concurrently access Filament APIs, OR
2. The Filament API is not safe to call from multiple threads, due to , OR
3. The Filament API is not safe to call from multiple threads, because the Filament team reserves the right to make changes in the future that would break this like

I ask because in my app, answer #1 makes life a lot easier in a couple of spots. For example, I have some code that creates/destroys a native OS window, and that really has to be done on a specific thread. So it is dramatically easier to create/destroy the Filament swap chain on that same thread. And my rendering thread that calls the Filament APIs is mutex-guarded anyway for other reasons, so it is very simple to lock out any other Filament API calls while doing so.

Is this safe? And if so, would you mind if I added a Filament option like FILAMENT_NO_ASSERT_SINGLE_THREAD to disable the debug assertions in CommandStream? :)

Thanks very much for your reply.