Fixed more threading issues with metaballs

This time issue was caused by static variables used in
BKE_scene_base_iter_next function.

Change is not so much ultimate actually, but didn't
find more clear solution for now. So the changes are:

- Wrap almost all the static variables into own context-
  like structure, which is owned by the callee function
  and getting passed to the iteration function.

- Recursion detection wasn't possible with such approach,
  so recursion detection still uses static in_next_object
  variable, but which is now stored in thread local
  storage (TLS, or thread variable if this names are more
  clear for you).

This makes code thread-safe, but for sure final solution
shall be completely different. Ideally, dependency graph
shall be possible to answer on question "which object is
a motherball for this metaball". This will avoid iterating
via all the bases, objects and duplis just to get needed
motherball.

Further, metaball evaluation ideally will use the same
kind of depsgraph filtering, which will get result for
question like "which objects belongs to this group of
metaballs".

But this ideal things are to be solved in Joshua's and
mind GSoC projects.

Tested on linux (gcc and clang) and windows (msvc2008),
hopefully no compilation error will happen.

Thanks to Brecht for reviewing the change and getting
feedback for other possible ways we've dicussed!

1 files changed, 7 insertions, 0 deletions

diff --git a/source/blender/blenlib/BLI_threads.h b/source/blender/blenlib/BLI_threads.h
index 154986936a2..ec558188270 100644
--- a/source/blender/blenlib/BLI_threads.h
+++ b/source/blender/blenlib/BLI_threads.h
@@ -182,6 +182,13 @@ int BLI_thread_queue_size(ThreadQueue *queue);
 void BLI_thread_queue_wait_finish(ThreadQueue *queue);
 void BLI_thread_queue_nowait(ThreadQueue *queue);
 
+/* Thread Local Storage */
+#ifdef _MSC_VER
+#  define ThreadVariable  __declspec(thread)
+#else
+#  define ThreadVariable  __thread
+#endif
+
 #ifdef __cplusplus
 }
 #endif