Scheduling framework.
The scheduler handles the timeouts, run the operations and does very basic management of coroutines. Most of the heavy logic is in each operation class. See: cogen.core.events and cogen.core.sockets. Most of those operations work with attributes we set in the scheduler.
cogen is multi-state. All the state related to coroutines and network is in the scheduler and it’s associated proactor. That means you could run several cogen schedulers in the same process/thread/whatever.
There is just one thing that uses global objects - the threadlocal-like local object in the coroutines module. It was actually aded for the wsgiserver factory that monkey patches the threadlocal module in order to make pylons run correctly (pylons relies heavily on threadlocals).
Bases: object
Basic deque-based scheduler with timeout support and primitive prioritisaiton parameters.
Usage:
mysched = Scheduler(proactor=DefaultProactor,
default_priority=priority.LAST, default_timeout=None)
Handle timeouts. Raise timeouted operations with a OperationTimeout in the associated coroutine (if they are still alive and the operation hasn’t actualy sucessfuly completed) or, if the operation has a weak_timeout flag, update the timeout point and add it back in the heapq.
weak_timeout notes:
Also, we call a cleanup on the op, only if cleanup return true we raise the timeout (finalized isn’t enough to check if the op has completed since finalized is set when the operation gets back in the coro - and it might still be in the Scheduler.active queue when we get to this timeout - well, this is certainly a problem magnet: TODO: fix_finalized)
The actual processing for the main loop is here.
Running the main loop as a generator (where a iteration is a full sched, proactor and timers/timeouts run) is usefull for interleaving the main loop with other applications that have a blocking main loop and require cogen to run in the same thread.