Thread Safety/Multiple Contexts

[john-chapman]

• Make internal::g_CurrentContext thread local by default (disable from config).
• Context merging API (simplest approach to MT will be to merge multiple contexts before making a single call to Im3d::Draw() - this alsonaturally supports sorted primitives between contexts).
• MT example.

Question: is it acceptable to rely on application code to avoid modifying any of the thread-local contexts during the merge operation? This means application threads cannot make Im3d calls while the main thread is merging contexts. Answer yes, there's basically no other way. The application must be responsible for locking modifications to a context, and the only tools which Im3d can provide are per-thread context ptrs and context merging.

That said, applications have a few choices for how to go about making Im3d thread safe:

• Per-thread context with merge, ensuring that no jobs/threads can modify a context during the merge.
• Per-thread context with merge, allocate 2 contexts per thread and atomically swap them prior to the merge.
• Single context but wrap the whole API. Pretty error prone but simple and avoids the merge cost - you basically do:

  LockIm3d();
  // Im3d calls...
  UnlockIm3d();

  Note that the application must fill AppData for each context.