doc/COROUTINE_MANAGEMENT

   1 Due to the issue w/ self-resuming threads and crashing out threads,
   2 a management system needs to be in place.
   3
   4 Example thread system:
   5
   6 MAIN
   7 EVENT_LOOP --------running---
   8 WAITING ON READ
   9 WAITING ON WRITE
  10 WAITING ON CONNECT
  11
  12
  13 Since main and the other 'waiting' threads are yielded, it is unsafe to call things arbitrarily on them
  14 or resume them from themselves...
  15 However the EVENT_LOOP one is running and thus can execute the callbacks (which can resume the threads)
  16 Each of the 'waiting' events are attached to an event and contain a pointer, this pointer can be setup to point
  17 to a per event_base item which will be updated w/ the lua_State of whatever calls EVENT_LOOP...
  18 this will guarantee that the thread will be resumed from the currently running EVENT_LOOP
  19
  20
  21 Other system that's more complicated and less likely:
  22
  23 MAIN
  24 EVENT_LOOP a -----running---
  25
  26 WAITING ON READ a
  27 WAITING ON WRITE a
  28
  29 EVENT_LOOP b ----yielded
  30 WAITING ON READ b
  31
  32
  33 Since there can only be one event_loop running per event_base, you do not have to worry about
  34 cross-pollination of the different waits...
  35
  36 NOTES:
  37 If the event_loop thread goes away... then the waiting coroutines will have no way to get back...
  38 though in this case, they are dead in the water anyways.. until a new event_loop starts...
  39 in which case the lua_State references has been updated...