| 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... |