Multithreading: schedule a task from a different thread

[Victor Stinner]

Hi,

I want to run asyncio event loop in its own thread, and schedule tasks
from the main thread (or a different thread). The problem is that
asyncio.async() is not "thread-safe": it doesn't wake-up the event
loop thread.

A workaround is to use: loop.call_soon_threadsafe(asyncio.async, ...,
loop=loop).

Is it a bug or is the workaround the right solution?

For your information, my question is for an event loop for the Olso
Messaging project, a component of OpenStack. See my work-in-progress
patchset:
https://review.openstack.org/#/c/70948

I also plan to use greenio to reuse greenlet event loop, so tasks
executed by asyncio will run in the main thread. But at least for my
tests, I would like to use a separated asyncio event loop running in a
dedicated thread.

Victor

[Guido van Rossum]

It is an intentional part of the design that all interaction with an event loop must be done from the thread owning that event loop, with the exception of call_soon_threadsafe().

--
--Guido van Rossum (python.org/~guido)

[Victor Stinner]

2014-02-04 Guido van Rossum <gu...@python.org>:

> It is an intentional part of the design that all interaction with an event
> loop must be done from the thread owning that event loop, with the exception
> of call_soon_threadsafe().

Ok, I completed the "Concurrency and multithreading" section of the
documentation to add the "call_soon_threadsafe(asyncio.async, ....)"
example:
http://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading
(I will be online in 1 hour)

Victor

[Guido van Rossum]

Thanks, I added a missing word (will be live in one hour :-).

I wonder about this sentence:

"""
To handle signals and to execute subprocesses, the event loop must be run in
the main thread.
"""

IIUC this is true for signals but it should not be so for subprocesses -- the child watcher infrastructure takes care of this (it even uses locks to make it thread-safe). Is that not your experience?