[Bf-blender-cvs] [f4f6e6f] asset-engine: AmberAIO: Fix asyncio loop handling.

[Bastien Montagne]

Commit: f4f6e6f525f39922f7982b27c404d3dc974e8987
Author: Bastien Montagne
Date:   Tue Sep 6 14:12:08 2016 +0200
Branches: asset-engine
https://developer.blender.org/rBf4f6e6f525f39922f7982b27c404d3dc974e8987

AmberAIO: Fix asyncio loop handling.

Finally found the right way to do this (at least, I think! :P).

===================================================================

M	release/scripts/startup/bl_operators/amber_asyncio.py

===================================================================

diff --git a/release/scripts/startup/bl_operators/amber_asyncio.py b/release/scripts/startup/bl_operators/amber_asyncio.py
index 14fdb38..d4821db 100644
--- a/release/scripts/startup/bl_operators/amber_asyncio.py
+++ b/release/scripts/startup/bl_operators/amber_asyncio.py
@@ -148,13 +148,17 @@ class AmberJob:
 
     @staticmethod
     def async_looper(func):
+        """Defines a simple wrapper around the function that executes it before stepping a bit asyncio loop."""
         def wrapper(*args, **kwargs):
             loop = asyncio.get_event_loop()
-            print("kickstop")
-            loop.stop()
             print("proceed....")
             func(*args, **kwargs)
-            print("kickstart")
+            print("kickstep")
+            # That's the trick - since asyncio loop is not the main loop, we cannot call run_forever, or we would
+            # never get back our thread (not until something in asyncio loop itself calls stop(), at least).
+            # So we schedule ourselves the stop call, effectively leading to 'stepping' asyncio loop.
+            # This relies on the fact that main loop (aka Blender) calls an @AmberJob.async_looper func often enough!
+            loop.call_soon(loop.stop)
             loop.run_forever()
         return wrapper