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