Mercurial > luaevent-prosody / file comparison
comparison: COROUTINE_MANAGEMENT
COROUTINE_MANAGEMENT
- changeset 39
- a0a7f7ebca3f
- parent 38
- 01374be0702d
- child 40
- 11810d219ddb
- child 63
- 1b8cbf640378
equal
deleted
inserted
replaced
| 38:01374be0702d | 39:a0a7f7ebca3f |
|---|---|
| 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... |
