A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-February/071190.html below:

[Python-Dev] microthreading vs. async io

[Python-Dev] microthreading vs. async ioAdam Olsen rhamph at gmail.com
Thu Feb 15 18:33:42 CET 2007
On 2/15/07, Joachim König-Baltes <joachim.koenig-baltes at emesgarten.de> wrote:
> 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

My tasks are transient and only wait on one thing at a time (if not
waiting for the scheduler to let them run!).  I have my own semantics
for creating tasks that incorporate exception propagation.  My
exception propagation (and return handling) require a scheduler with
specific support for them.  Net result is that I'd have to wrap all
you provide, if not monkey-patching it because it doesn't provide the
interfaces to let me wrap it properly.

All I want is a global select.poll() object that all the event loops
can hook into and each will get a turn to run after each call.

Well, that, plus I want it to work around all the platform-specific
peculiarities.


-- 
Adam Olsen, aka Rhamphoryncus
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4