[Python-Dev] microthreading vs. async io (original) (raw)
Joachim König-Baltes joachim.koenig-baltes at emesgarten.de
Thu Feb 15 16:28:17 CET 2007
- Previous message: [Python-Dev] microthreading vs. async io
- Next message: [Python-Dev] generic async io (was: microthreading vs. async io)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Adam Olsen schrieb:
I don't think we're on the same page then. The way I see it you want a single async IO implementation shared by everything while having a collection of event loops that cooperate "just enough". The async IO itself would likely end up being done in C. No, I'd like to have:
- An interface for a task to specifiy the events it's interested in, and waiting for at least one of the events (with a timeout).
- an interface for creating a task (similar to creating a thread)
- an interface for a schedular to manage the tasks
When a task resumes after a wait(...) it knows which of the events it was waiting for have fired. It can then do whatever it wants, do the low level non blocking IO on its own or using something else. Of course, as these are cooperative tasks, they still must be careful not to block, e.g. not reading to much from a file descriptor that is readable, but these problems have been solved in a lot of libraries, and I would not urge the task to use a specific way to accomplish its "task".
The problem solved by this approach is to allow a number of cooperating threads to wait for an event without the need to busy loop or block by delegating the waiting to a central instance, the scheduler. How this efficient waiting is implemented is the responsability of the scheduler, but the schedular would not do the (possibly blocking) io operation, it would only guaranty to continue a task, when it can do an IO operation without blocking.
Joachim
- Previous message: [Python-Dev] microthreading vs. async io
- Next message: [Python-Dev] generic async io (was: microthreading vs. async io)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]