"Tail recursion" in callbacks about asyncio

[GoogleCodeExporter]

Agree in general, as we discussed today.
Not sure about connection_made() call.
Should it be specific?
It's called once per protocol instance and may generate new connections as well.
I vote to leave if delayed (I mean call_soon).

Original comment by [email protected] on 21 Mar 2013 at 2:16

[GoogleCodeExporter]

I don't actually see any qualifying occurrences of call_soon(connection_made, 
...).

Original comment by [email protected] on 21 Mar 2013 at 3:14

[GoogleCodeExporter]

new code changed semantic of _read_ready()

was: read data from all ready sockets then process
now: read one ready socket - process, read next ...

UnixSubprocessTransport uses call_soon as well.

Original comment by [email protected] on 22 Mar 2013 at 11:19

[GoogleCodeExporter]

I'm not sure it's bad though.

Suppose 3 out of 10 sockets are returned as "ready" by the selector.  Then the 
_read_ready callback is scheduled using call_soon() for each of them.  In the 
old way, the three _read_ready callbacks would each read some data off their 
socket, schedule their protocol.data_received callback using call_soon(), then 
_run_once() would loop back and do *another* polling loop, and then finally the 
three data_received callbacks would be run.

Using the new approach, all data would be read *and* all the data_received 
callbacks called before going back to I/O polling.  So there would be fewer I/O 
poll calls to process the same amount of data.  I think that's a win.

Original comment by [email protected] on 22 Mar 2013 at 11:27

[GoogleCodeExporter]

Please review https://codereview.appspot.com/8416045/

Original comment by [email protected] on 7 Apr 2013 at 1:01

[GoogleCodeExporter]

Fixed in 
https://code.google.com/p/tulip/source/detail?r=8700bc263f1c661c5cb6701524649fb7
94af8b0f
Close the issue.

Original comment by [email protected] on 13 Apr 2013 at 5:09

• Changed state: Fixed