在Python asyncio库中，我使用BaseEventLoop.run_in_executor函数在一个单独的线程上安排长时间运行的阻塞函数：
jenkins@9031c65c8952:~$ ssh core@10.45.1.107 -vvvv
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.45.1.107 [10.45.1.107] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/jenkins/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/jenkins/.ssh/id_rsa type 1
debug1: identity file /home/jenkins/.ssh/id_rsa-cert type -1
debug1: identity file /home/jenkins/.ssh/id_dsa type -1
debug1: identity file /home/jenkins/.ssh/id_dsa-cert type -1
debug1: identity file /home/jenkins/.ssh/id_ecdsa type -1
debug1: identity file /home/jenkins/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/jenkins/.ssh/id_ed25519 type -1
debug1: identity file /home/jenkins/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7
debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "10.45.1.107" from file "/home/jenkins/.ssh/known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /home/jenkins/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-sha1-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug2: mac_setup: setup hmac-sha1-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ED25519 54:85:33:0a:6f:78:74:a7:13:7d:74:bd:03:f1:9c:ce
debug3: load_hostkeys: loading entries for host "10.45.1.107" from file "/home/jenkins/.ssh/known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /home/jenkins/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '10.45.1.107' is known and matches the ED25519 host key.
debug1: Found key in /home/jenkins/.ssh/known_hosts:1
debug1: ssh_ed25519_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jenkins/.ssh/id_rsa (0x7fab14d1cab0),
debug2: key: /home/jenkins/.ssh/id_dsa ((nil)),
debug2: key: /home/jenkins/.ssh/id_ecdsa ((nil)),
debug2: key: /home/jenkins/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jenkins/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 53:f8:88:06:5b:c2:a3:0a:05:9f:2c:ed:3b:51:74:47
debug3: sign_and_send_pubkey: RSA 53:f8:88:06:5b:c2:a3:0a:05:9f:2c:ed:3b:51:74:47
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 10.45.1.107 ([10.45.1.107]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env LESSOPEN
debug3: Ignored env LESSCLOSE
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Mon Jul 27 09:49:44 2015 from 172.17.0.37
CoreOS stable (717.3.0)
core@localhost ~ $
当我将PYTHONASYNCIODEBUG env var设置为启用asyncio调试日志记录时，我会看到以下警告定期打印到文本自动收报机（添加换行符）：
yield from loop.run_in_executor(None, long_running_blocking_function)
我对此感到惊讶，因为我认为run_in_executor函数专门用于将阻塞函数移交给另一个线程？任何人都可以对此有所了解吗？感谢
编辑：正如下面对Nihal的评论中所提到的，问题似乎在于使用执行程序将一些库代码与asyncio集成在一起。以下是一些有助于描述问题的示例代码：
WARNING:asyncio:Executing <Task pending coro=<long_running_blocking_function()
running at C:/Projects/Blah/blah.py:52>
wait_for=<Future pending cb=[wrap_future.<locals>._check_cancel_other() at
C:\Python34-64\lib\asyncio\futures.py:401, Task._wakeup()] created at
C:\Python34-64\lib\asyncio\futures.py:399> created at
C:/Projects/Blah/blah.py:59> took 0.999 seconds
当我注释掉驱动update_session函数的Task时，我看到我的sleep_short函数每0.01秒被调用一次。
def on_data(*args, **kwargs):
logger.info('Received data %s', args[1])
def blocking_function(t):
logger.info('Going to sleep for %s', t)
time.sleep(t)
executor = ThreadPoolExecutor(2)
@asyncio.coroutine
def update_session():
while True:
# session.Update causes on_data to be called when data is available
yield from loop.run_in_executor(executor, session.Update, -1)
@asyncio.coroutine
def sleep_short():
while True:
yield from loop.run_in_executor(executor, blocking_function, .01)
asyncio.Task(update_session())
asyncio.Task(sleep_short())
loop = asyncio.get_event_loop()
loop.run_forever()
但是，包含该任务似乎劫持了两个线程，因此sleep_short任务每隔一秒左右运行一次：
2015-07-27 17:57:09,570 [MainThread] Using selector: SelectSelector
2015-07-27 17:57:09,577 [Thread-1] Going to sleep for 0.01
2015-07-27 17:57:09,587 [Thread-1] Going to sleep for 0.01
2015-07-27 17:57:09,597 [Thread-2] Going to sleep for 0.01
我很困惑......我可能会遇到GIL吗？
编辑2：
延迟肯定是由GIL引起的。我期待我要调用的库在IO上阻塞，但显然事实并非如此。
答案 0 :(得分：0)
我会尝试给出一些解释，我对asyncio也很陌生。
可能发生这种情况的一种情况是 - 假设您已经启动了一些连接，并且在事件循环关闭之前连接尚未关闭。在这种情况下，循环应等待关闭连接然后自行关闭。这曾经经常出现在asyncio's redis模块中，此处报告的错误可以作为参考 - https://github.com/jonathanslenders/asyncio-redis/issues/56
我不确定这是否能妥善解决问题。