Using asyncio workers in a `concurrent.futures` interface

[Ian Kelly]

On Tue, Aug 12, 2014 at 11:03 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>
> Ian Kelly <ian.g.kelly at gmail.com>:
>
> > On Tue, Aug 12, 2014 at 11:02 AM, cool-RR <ram.rachum at gmail.com> wrote:
> >> And that's it, no coroutines, no `yield from`. Since, if I understand
> >> correctly, asyncio requires a mainloop, it would make sense for the
> >> AsyncIOExecutor to have a thread of its own in which it could run its
> >> mainloop.
> >
> > I think that putting the event loop in a separate thread would be
> > necessary if the intention is that the executor be invoked from
> > outside. I'm not aware of this work having been done, but it sounds
> > perfectly feasible.
>
> Multithreading will require normal locking to protect critical sections.
> Care must be taken to never yield while holding a threading lock.

You can use event_loop.call_soon_threadsafe() to schedule tasks and
callbacks on the event loop, and Queue objects to pass futures back to the
caller. Apart from whatever synchronization those use internally, I don't
think any locking would be needed.

However, it would of course require that the "functions" passed in to the
executor be coroutines in actuality. You just can't pass a blocking
function into an asynchronous framework and expect it to magically not
block.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140813/cce16b30/attachment.html>