# HG changeset patch # User Thomas Harning Jr # Date 1190391052 14400 # Node ID a0a7f7ebca3f9d5d318f9cd2dd0f7bfd052dfdd0 # Parent 01374be0702d32e9067fefff650a5dc9bddda5a5 Relocated the COROUTINE_MANAGEMENT document... diff -r 01374be0702d -r a0a7f7ebca3f COROUTINE_MANAGEMENT --- a/COROUTINE_MANAGEMENT Fri Sep 21 12:02:14 2007 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,39 +0,0 @@ -Due to the issue w/ self-resuming threads and crashing out threads, -a management system needs to be in place. - -Example thread system: - -MAIN -EVENT_LOOP --------running--- -WAITING ON READ -WAITING ON WRITE -WAITING ON CONNECT - - -Since main and the other 'waiting' threads are yielded, it is unsafe to call things arbitrarily on them -or resume them from themselves... -However the EVENT_LOOP one is running and thus can execute the callbacks (which can resume the threads) -Each of the 'waiting' events are attached to an event and contain a pointer, this pointer can be setup to point -to a per event_base item which will be updated w/ the lua_State of whatever calls EVENT_LOOP... -this will guarantee that the thread will be resumed from the currently running EVENT_LOOP - - -Other system that's more complicated and less likely: - -MAIN -EVENT_LOOP a -----running--- - -WAITING ON READ a -WAITING ON WRITE a - -EVENT_LOOP b ----yielded -WAITING ON READ b - - -Since there can only be one event_loop running per event_base, you do not have to worry about -cross-pollination of the different waits... - -NOTES: -If the event_loop thread goes away... then the waiting coroutines will have no way to get back... -though in this case, they are dead in the water anyways.. until a new event_loop starts... -in which case the lua_State references has been updated... \ No newline at end of file diff -r 01374be0702d -r a0a7f7ebca3f doc/COROUTINE_MANAGEMENT --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/COROUTINE_MANAGEMENT Fri Sep 21 12:10:52 2007 -0400 @@ -0,0 +1,39 @@ +Due to the issue w/ self-resuming threads and crashing out threads, +a management system needs to be in place. + +Example thread system: + +MAIN +EVENT_LOOP --------running--- +WAITING ON READ +WAITING ON WRITE +WAITING ON CONNECT + + +Since main and the other 'waiting' threads are yielded, it is unsafe to call things arbitrarily on them +or resume them from themselves... +However the EVENT_LOOP one is running and thus can execute the callbacks (which can resume the threads) +Each of the 'waiting' events are attached to an event and contain a pointer, this pointer can be setup to point +to a per event_base item which will be updated w/ the lua_State of whatever calls EVENT_LOOP... +this will guarantee that the thread will be resumed from the currently running EVENT_LOOP + + +Other system that's more complicated and less likely: + +MAIN +EVENT_LOOP a -----running--- + +WAITING ON READ a +WAITING ON WRITE a + +EVENT_LOOP b ----yielded +WAITING ON READ b + + +Since there can only be one event_loop running per event_base, you do not have to worry about +cross-pollination of the different waits... + +NOTES: +If the event_loop thread goes away... then the waiting coroutines will have no way to get back... +though in this case, they are dead in the water anyways.. until a new event_loop starts... +in which case the lua_State references has been updated... \ No newline at end of file