Tukukkk

I have tried the following code in Python 3.6 for asyncio:
Example 1:

import asyncio

import time



async def hello():



    print('hello')

    await asyncio.sleep(1)

    print('hello again')



tasks=[hello(),hello()]    

loop=asyncio.get_event_loop()

loop.run_until_complete(asyncio.wait(tasks))

Output is as expected:

hello

hello

hello again

hello again

Then I want to change the asyncio.sleep into another def:

async def sleep():

    time.sleep(1)



async def hello():



    print('hello')

    await sleep()

    print('hello again')





tasks=[hello(),hello()]    

loop=asyncio.get_event_loop()

loop.run_until_complete(asyncio.wait(tasks))

Output:

hello

hello again

hello

hello again

It seems it is not running in an asynchronous mode, but a normal sync mode.

The question is: Why is it not running in an asynchronous mode and how can I change the old sync module into an 'async' one?

Asyncio uses an event loop, which selects what task (an independent call chain of coroutines) in the queue to activate next. The event loop can make intelligent decisions as to what task is ready to do actual work. This is why the event loop also is responsible for creating connections and watching file descriptors and other I/O primitives; it gives the event loop insight into when there are I/O operations in progress or when results are available to process.

Whenever you use await, there is an opportunity to return control to the loop which can then pass control to another task. Which task then is picked for execution depends on the exact implementation; the asyncio reference implementation offers multiple choices, but there are other implementations, such as the very, very efficient uvloop implementation.

Your sample is still asynchronous. It just so happens that by replacing the await.sleep() with a synchronous time.sleep() call, inside a new coroutine function, you introduced 2 coroutines into the task callchain that don't yield, and thus influenced in what order they are executed. That they are executed in what appears to be synchronous order is a coincidence. If you switched event loops, or introduced more coroutines (especially some that use I/O), the order can easily be different again.

Moreover, your new coroutines use time.sleep(); this makes your coroutines uncooperative. The event loop is not notified that your code is waiting (time.sleep() will not yield!), so no other coroutine can be executed while time.sleep() is running. time.sleep() simply doesn't return or lets any other code run until the requested amount of time has passed. Contrast this with the asyncio.sleep() implementation, which simply yields to the event loop with a call_later() hook; the event loop now knows that that task won't need any attention until a later time.

Also see asyncio: why isn't it non-blocking by default for a more in-depth discussion of how tasks and the event loop interact. And if you must run blocking, synchronous code that can't be made to cooperate, then use an executor pool to have the blocking code executed in a separate tread or child process to free up the event loop for other, better behaved tasks.