Yes, this is all by design. The *only* operation in all of asyncio that's thread-safe is call_soon_threadsafe(). I don't see a reason to add more hybrid methods, but I do think we should provide an example about how a thread and an event loop can communicate using some kind of queue. (There are a few approaches here -- e.g. you could use a regular thread-safe queue.Queue and use run_in_executor() to wrap the q.get() call, or you could use an asyncio Queue and make a thread-safe wrapper to put something into it.)
On Wed, Feb 25, 2015 at 8:00 AM, Victor Stinner <[email protected]> wrote: > 2015-02-25 16:23 GMT+01:00 Andrew Svetlov <[email protected]>: > > I'm OK with current asyncio locks and queue implementation, they are > > not-threadsafe by design explicitly. > > Ok, it expected this answer. It is a more a documentation issue than a > design issue :-) > > > For locks you can use `yield from lock.acquire()` (requires nested > > function definition for passing into `loop.call_soon_threadsafe()`) > > and `lock.release()`. > > If you use a nested function and call_soon_threadsafe(), you can use > "with (yield from lock):". > > I will add "This class is not thread safe." to all lock classes. > > But it would help to have a short examples showing how to: > - share a queue between multiple coroutines > - use a lock in coroutines > > And maybe also examples with multiple threads: > > - "share" a queue between multiple coroutines running in different > threads (in different event loops) > > Victor > -- --Guido van Rossum (python.org/~guido)
